UML: Cmo construir sistemas con mtodo.

No de Visitas... 24
Por: Revista BYTE

La comunidad informtica es similar a las de otras reas profesionales. Adolece de sus

propios problemas, tiene sus propias metodologas, sus estndares, sus gurus y sus
propios trucos y soluciones. Pero quiz la informtica se distinga por tener una desventaja
aadida comparada con otras actividades, y es que a menudo tiene que ofrecer soluciones y
colaborar con el resto de reas profesionales. Segn va transcurriendo la azarosa vida
profesional del analista/programador, ste va absorbiendo diversas metologas de trabajo
derivadas de la experiencia y los conocimientos de las profesiones y profesionales con los
que ha tenido que colaborar. En unos cuantos aos, nuestro informtico de pie se habr
sumergido en los secretos de la contabilidad, de los distintos sistemas de burocracia
(contratos, seguros, administraciones, fincas, seguridad social, etc.), en el campo de la
ingeniera, ver algo de fsica, matemticas, logstica, marketing, electrnica, diseo,
arquitectura, y cualquier otro campo en el que un necesitado usuario requiera de sus
servicios.
Por otro lado, el informtico de hoy en da no suele corresponder al perfil del alumno de la
carrera de informtica, sino que la mayora de las veces se trata de una persona autodidacta
en este campo, que a fuerza de tiempo, ganas e ilusin, ha sido comprendiendo qu
demonios pasa dentro de esas cajas blancas que estn por las oficinas, y ha terminado
trabajando (quizs triunfando) en este campo. No resulta extrao encontrarse con buenos
programadores o analistas que provienen de otras careras como pueden ser fsicas,
ingenieras o empresariales (personalmente conozco a un par de historiadores muy buenos
profesionales informticos). Por esta razn, el da a da de la informtica transcurre a veces
entre choques entre diversas metodologas, derivadas la mayor parte de las veces de la
propia personalidad y experiencia de los integrantes del equipo de trabajo. La mayora de los
programas y el cdigo que se escribe se podra decir que estn hechos sin ningn tipo de
planificacin, ms all de la que cada uno se hace en su cabeza media hora antes de ponerse
manos al teclado. Esta forma de trabajo aunque parezca mentira funciona, pero lo hace
nicamente hasta que se llega a una complejidad de proyecto determinado. Es decir,
podemos encargar un programa o proyecto pequeo a unos programadores, y lo podrn
desarrollar de una manera satisfactoria. As se pueda trabajar (y se trabaja ) durante aos,
pero cuando los proyectos comienzan a crecer en dimensiones aumenta la complejidad, el
nmero de objetos utilizados, las necesidades de reutilizacin y el nmero de personas
implicadas. Entonces el desastre al que nos enfrentamos puede ser fenomenal.
En estos difciles momentos cuando nuestro sufrido encargado de proyecto se quedad con la
mirada ausente y perdida en el vaco y se pregunta cmo podra mejorar el sistema de
trabajo.
Qu es, para qu sirve y de donde proviene UML
UML significa Lenguaje de Modelado Unificado (Unifield Modeling Lenguaje) y es un
lenguaje grfico creado para ofrecer una solucin a la hora de construir o planificar un sitema
sotware.o cualquier otro modelo de negocio, est relacionado con el campo del software o
no.
El lenguaje UML no es el nico en su campo y proviene de otros lenguajes o modelos previos
tales como mtodos Booch`93 y OMT-2. La ventaja de UML es que es precisamente un
compendio de las mejores cualidades del resto de mtodo, ya que fue creado por los tres
gurs ms reconocidos en este campo, sin contar con las colaboraciones de mltiples
empresas y de la comunidad informtica en general.
Entre los participantes del proyecto destacan por ser los principales creadores Jim Rumbaugh
(pronunciado Rumb), el creador del conocido sistema OMT, que significa Tcnica de
Modelado de Objetos (Object Modeling Technique), Grady Booch (creador del sistema que
lleva su apellido), e Ivar Jacobson, que defini de casos de uso, que veremos ms
adelante.
Si usted ya estaba o est interesado en el tema de este artculo, o si comienza a interesarse
despus de leerlo, empezar a ver estos tres nombres hasta en la sopa, ya que son citados
prcticamente en la mayora de las obras sobre UML u otros sistemas de modelado. Son
indiscutiblemente las tres personas ms influyentes en este campo y su autoridad est bien
merecida.
A la par, usted empezar a visitar ciertos Webs de Internet y a leer ciertos libros (es algo
parecido a una secta...).

Con seguridad uno de estos sitios sea el de la OMG (www.omg.org), y otro el de Rational
Software (www.rational.com). La OMG es un organismo creado en 1989, est formado por el
esfuerzo conjunto de diversas compaas representativas en el campo de la informtica.
Tiene la finalidad de crear mercado para el desarrollo asistido por tcnicas de modelado de
objetos. Si en Internet buscamos informacin sobre estndares y protocolos en los
documentos RFC, todo lo concerniente a estndares o propuestas sobre sistemas orientados
a objetos los buscaremos en los archivos de la OMG. Entre otras especificaciones, poseen la
autora del famoso protocolo IIOP, estrechamente relacionado con otro de sus campos de
accin ms importantes, como es CORBA, y publican las especificaciones de otros sistemas
como pueden ser IDL y UML (la ltima es el draft de la 1.3).
Por otro lado tenemos a Rational Software Corporation, con una orientacin mucho ms
comercial, y que desarrollan aplicaciones para las plataformas Windows y UNIX relacionadas
con los sistemas de modelado tecnologas de objetos. Uno de sus productos ms exitosos es
el Rational Rose, una herramienta de modelado visual que implementa una versin de UML.
El objetivo de este artculo no es el de profundizar en el estudio de UML. Este objetivo
resultara del todo inalcanzable debido a la extensin y carcter prctico de este sistema (la
ltima especificacin de UML, la 1.3, ocupa ms de 600 pginas), sino el de utilizar a UML
como elemento introductorio a lo que sera una nueva organizacin en su forma de orientar
el diseo de software (sea el caso de que no est utilizando ninguna todava). Hay que
advertir que alejndonos del estricto sentido acadmico del sistema, en muchas ocasiones el
mtodo utilizado, ya sea UML, OMT, Booch o alguna aproximacin de factura propia, no es
ms que la excusa utilizada para implementar cierto orden en lo que suele ser una labor
catica.
Beneficios de UML
Actualmente, trabajando sobre plataformas Windows o Unix, la orientacin a objetos de los
programas cada vez se hace ms patente y fundamental, gracias a las nuevas tecnologas
emergentes.
La migracin que Windows viene experimentando hacia tecnologas orientadas a objetos se
hace patente en la importancia que la misma compaa, y la mayora de fabricantes de
software, le da a la tecnologa COM. En los foros de programacin cada vez se habla menos
de las API, tan profusamente utilizadas antao, y cada vez los temas de conversacin
convergen ms hacia COM, ActiveX, Java, COBA, IDL, ATL, etc. Por fin empieza a ver un
mercado real de objetos, con empresas enteras dedicadas a la produccin y venta exclusiva
de objetos COM y Java, y las aplicaciones cada vez dependen ms de un diseo modular,
sobre todo las aplicaciones relacionadas con el campo de las comunicaciones, sistemas
distribuidos e Internet.
Si antao el desarrollo de un programa consista en dividirlo para poder programar sus
funciones bsicas, ahora la divisin se produce de igual forma, con la diferencia de que ya no
se programan funciones, sino que se programan objetos.
Un objeto, como ya probablemente sepa, es un conjunto de datos y funciones que operan
sobre dichos datos. Los objetos encapsulan (nos ocultan) su funcionamiento interno, de tal
forma que lo nico que conocemos de un objeto son las propiedades que tiene, y la
especificacin de los mtodos que nos ofrece.
Lo que UML nos permite es crear un modelo a partir de ciertos elementos y ciertas tcnicas,
que nos permita representar nuestro sistema. UML es un sistema abierto y en un primer
contacto quizs le parezca incluso simplista, ya que la representacin bsica est pensada
para poder visualizarse tanto dentro de un programa dedicado al diseo UML, como en una
hoja de papel comn.
Por lo tanto, y aunque existen muchas herramientas de diseo UML, este lenguaje no
necesita de una herramienta software concreta, sino que por el contrario, podremos hacer
uso de l en distintos soportes.
UML se basa en diagramas, y cuenta con nueve tipos de diagramas distintos. Cada uno de
estos diagramas se centra en un aspecto del sistema y ataca y resuelve una serie de
caractersticas o situaciones distintas. Un diagrama es normalmente un grafo, y conserva una
propiedad en comn con el resto, que es la flexibilidad.
Cuando piense en los diagramas UML, no piense en ningn momento en sistemas
cuadriculados, con reglas y esquemas complicados. Por el contrario, el nivel de integracin
que queramos conseguir con UML depende de nosotros mismos.
El hecho fsico (que no el intelectual) de construir un diagrama UML no va ms all de coger

una hoja de papel y garabatear un par de flechas y recuadros.

Esta flexibilidad est pensada precisamente para que no sea el sistema de representacin el
que domine al mtodo, y podamos centrarnos en el trabajo de definir nuestros objetos y
operaciones, sin tener que preocuparnos en exceso sobre los aspectos formales de la
herramienta que estamos utilizando. Igualmente UML no es lenguaje de programacin. UML
se puede referir virtualmente, a cualquier lenguaje que est medianamente orientado a
objetos. Los lenguajes ms idneos para hacer realidad los diseos basados en UML son los
habituales C+ +, Java, Eiffel, Visual Basic o Delphi.
Trabajando con UML
Los nueve diagramas que tenemos a nuestra disposicin a la hora de realizar un modelo UML
de un sistema son los siguientes (por orden alfabtico): Diagrama de actividades, casos de
uso, clases, colaboracin, componentes, despliegue, estados, objetos y secuencia.
Cada uno de ellos nos muestra el sistema desde un punto de vista diferente. En cada uno de
estos diagramas, nos basamos en componentes simples, que nos permiten representar
elementos reales, con todas las propiedades y datos que necesitemos. Igualmente,
podremos representa las relaciones que existen entre dichos componentes.
Tenemos que tener en cuenta que estamos realizando un anlisis de un sistema que nos
llevar a tener un modelo UML formado por distintos diagramas, con diversos elementos y
las elaciones entre ellos. En ningn momento nuestro modelo pretender entrar en detalles
tcnicos tales como el tipo de almacenamiento, rutinas concretas, recursos del sistema
(memoria, disco, etc.) utilizados, ni el hardware bajo el que funciona la aplicacin. El modelo
UML es una vista general de objetos y funcionamiento global. Es por dicha razn por lo que
UML casa mejor con proyectos orientados a objetos u operaciones que con programas ms
tcnicos u orientados a algoritmos muy definidos. En la prctica, vamos a sacar ms
provecho de UML al utilizarlo para modelar una aplicacin de facturacin que para un
programa que calcule el nmero PI con millones de decimales. Cuanto ms complejo resulte
nuestro sistema en cuestin de objetos y relaciones, ms rendimiento obtendremos al haber
desarrollado previamente un modelo UML.
Una de las preguntas que uno se hace cuando empieza a trabajar con UML o con alguna
metodologa similar, es si el hecho de desarrollar un modelo previo puede llegar a ser
improductivo, ya que experiencia nos dice que las especificaciones de los proyectos pueden
estar sujetas mltiples cambios, como los aadidos por el cliente, por el cambiante mercado,
o por errores de diseo en los objetivos o especificaciones iniciales. Los beneficios que
conseguimos de UML en este caso son el dar a nuestro sistema una lgica inicial que sea
capaz de absorber cambios futuros, sin hacer el infame espagueti code, tan habitual en
nuestros das. El ciclo de vida de nuestro proyecto puede as realimentarse a s mismo de
una forma natural, con una marca de referencia en el modelo UML, que aunque es
susceptible de cambios, nos permite evaluar dichos cambios, y situarlos debidamente en el
contexto adecuado.
Pongamos un ejemplo, si una vez desarrollada nuestra aplicacin el cliente nos pide un
cambio (uno de esos pequeos cambios que suelen pedir los clientes dos das antes de
entregar el proyecto)..
Cmo integraremos dicho cambio?, y cmo afectar dicho cambio al resto de componentes
de nuestro programa?. Con la ayuda de UML podremos dar respuesta a estas preguntas, y la
robustez de nuestro software no se ver comprometida.

Breves conceptos sobre objetos

Antes de que usted comience su andadura con UML o con cualquier otro lenguaje de
modelado, tendr que familiarizarse con una serie de trminos y conceptos que se suelen
utilizar en este campo, y que es probable que ya maneje con soltura.
Dos de los ms importantes son el de clase y el de instancia. Una clase es la especificacin
que engloba las caractersticas sobre propiedades y mtodos comunes de una familia de
objetos. La instancia, por lo tanto es cada uno de esos objetos que han sido creados
mediante dicha especificacin. Por consiguiente tenemos que tener claro que mientras
manejemos el concepto de clase estaremos manejando especificaciones, mientras que un

objeto o instancia es el resultado de crear un elemento a partir de dicha especificacin.

Estos conceptos probablemente ya los maneje si est usted acostumbrado a utilizar algn
lenguaje orientado a objetos. Lo importante es que el concepto de clase nos lleva a otro ms
interesante que es la abstraccin.
La abstraccin es un concepto fundamental en el diseo de sistemas orientados a objetos, ya
que lo que significa es que nuestra forma de orientar o atacar el diseo de un modelo de
objetos no est ligado a la forma en que vamos a desarrollar nuestro cdigo, sino ms bien
se interesa en cmo son y qu hacen las clases que vamos a disear.
Mediante la abstraccin definiremos clases que realizan operaciones puntuales, adecuadas a
las necesidades de su entorno, pero sin entrar en la forma en que realizarn su actividad. Es
decir, yo podra definir una clase semforo que controlase el flujo de trfico en una calle, y
estara haciendo un ejercicio de abstraccin al definir las propiedades y mtodos de la clase
semforo, pero mi tarea no entrara en la forma en que internamente trabaja el semforo.
Desde este punto de vista, no me importa si el semforo es un conjunto de cables, si est
programado en C+ + o Java. Lo que yo veo del semforo es la abstraccin de su
funcionalidad. Con UML trabajaremos de una forma parecida, haciendo abstraccin de las
clases y objetos que utilizaremos.

Los casos de uso

La longitud de este artculo no da para estudiar uno por uno todos los diagramas que
tenemos a nuestra disposicin en UML, y por lo tanto, vamos a ver uno de los ms
representativos o fciles de entender, que es el diagrama de casos de uso. El diagrama de
casos de uso fue creado por Ivar Jacobson, gur de la compaa Rational, creador asimismo
de uno de los sistemas predecesores de UML, denominado OOSE (Object Oriented Software
Engineering).
Este diagrama viene a suplir todos aquellos documentos redactados a medias entre tcnicos
y comerciales en los que difusamente se especifican las tareas de una aplicacin, y que tan
perniciosos resultan para el diseo de la misma. Estos documentos, llamados
especificaciones, resultan la mayor parte de las ocasiones incompletos, ya que el estudio que
hacen sobre las necesidades de la aplicacin y de los usuarios que la utilizarn no depende
de mtodo alguno.
El diagrama de casos de uso de los ms tiles a la hora de definir qu har nuestra
aplicacin. Se compone bsicamente de una figura llamada actor (personas o cosas que
interactan con la aplicacin), los casos de uso, y las relaciones entre ambos.
Para realizar el estudio de los casos de uso, se debe estudiar la aplicacin en base a
descubrir qu interaccin tienen los distintos usuarios con el sistema (un administrador, un
usuario o un cliente pueden ser actores que dependiendo de la situacin, pidan ciertos datos
o realicen ciertas operaciones con nuestra aplicacin)
Este estudio deber clarificar qu tipo de informacin intercambia (aade, borrar, modifica o
consulta) el actor, y en que situacin y a qu otros casos de uso afecta.
Como puede ver en la figura adjunta, el diagrama de un caso de uso sorprende por su
sencillez. El actor se representa por un mueco y el caso de uso por un crculo.
Realmente la sencillez de este modelo (que como supondr, puede llegar a ser ms
complicado), no est en contra de lo es el modelo real. Si nuestro caso de uso es muy
complicado, probablemente podr descomponerse en otros ms sencillos.
Como puede comprobar, el campo del diseo de sistemas orientados a objetos no resulta
difcil de entender, pero tiene una trampa oculta: si bien los conceptos son sencillos, llegar a
dominar todas las herramientas, y lo que es ms, llegar a realizar buenos modelos de
aproximacin en UML, puede resultar una tarea difcil, ya que requiere de un alto grado de
experiencia previa como programadores y como analistas. Quiz a usted no le interese llegar
a implementar UML de una forma estricta, y realmente lo que necesite usted o su empresa
es una aproximacin al modelado de sistemas. El desarrollo estricto de una metodologa de
creacin de sistemas puede resultar excesivamente costoso si su actividad no est cercana a
la de la consultora. En cualquier caso debe pensar en que la planificacin cada vez es ms
necesaria en el campo del software, y que el tiempo de la programacin heroica, en la que
un solo programador con todo el conocimiento resolva nuestros problemas a base de pasar
noches en vela ha terminado, o por lo menos est en camino de terminar.
Entre por sus propios medios en el mundo del modelado y planificacin de sistemas

orientados a objetos, y evale usted mismo los beneficios y costes de estas opciones. Suerte
en su tarea.