Una Introducción a los conceptos clave en UML aplicados al desarrollo Flash

Como bien dijo Andrés Felipe en un post anterior estaría bien publicar mis artículos de FlashWeek en su versión española, ya que este blog empezó siendo un intento de traer información en nuestro idioma a la comunidad de Flash. Así que aquí va la traducción de mi último artículo (para el que quiera ver el original en inglés, dejo nuevamente el link).

Una Introducción a los conceptos clave en UML aplicados al desarrollo Flash

Si estás planeando hacer un proyecto totalmente Orientado a Objetos (OOP) con Flash desde cero, deberías considerar el empezar planificando y organizando bien tus ideas con la ayuda de UML. UML(Unified Modeling Languaje) lleva con nosotros casi una década y se ha convertido en una de las principales herramientas del desarrollador de aplicaciones. En un proyecto Flash también puedes usar UML dibujando diagramas que representen tus clases, interfaces y paquetes y la relación entre ellos de manera que a la hora de empezar a codificar seas más eficiente. Lo primero es aprender cuales son las herramientas gráficas que nos aporta UML y a que conceptos OOP corresponden.

Conceptos de relacción clave en UML

Como puedes ver, en la figura 1 aparecen algunos diagramas representando conceptos OOP clave que puedes usar para hacer diagramas bien construidos de tus clases, interfaces y paquetes. Vamos a ir comentando algunos aspectos de cada concepto reflejado en el gráfico.

Tipos de relación en UML

Paquetes. Los Paquetes son usados tradicionalmente para prevenir colisiones entre los nombres de las clases. Esto se lleva a cabo dando un espacio de nombres que se representa en el código mediante la siguiente notación: paquete.PaqueteAnidado.nombreClase. La notación lógica dada mapea una estructura física de carpetas. Puedes representar un paquete como una caja con una etiqueta que envuelve sus propias clases e interfaces. La etiqueta antes mencionada es el nombre del paquete.

Herencia. Como ya sabrás este es uno de los pilares de la programacion orientada a objetos. Aquí la subclase “hereda” de la superclase, es decir la subclase “es una”(is a) superclase que tendra las mismas caracteristicas que dicha superclase mas algunas propias que marcarán la diferencia. Esta relacion se representa mediante una flecha blanca que parte de la subclase y termina en la superclase.

Composicion. En este caso la relacion a representar se denomina “tiene una”(has a). Es decir la superclase “tiene” uno o más miembros del tipo subclase. En caso de destruir la superclase, las subclases también serán destruidas puesto que forman parte del todo. La representacion es la de una linea desde la superclase a la subclase con un simbolo en forma de diamante negro en el lado de la superclase. De manera opcional puedes especificar cuantas instancias pueden ser guardadas por la superclase.

Aggregation. Similar a la composicion, pero aquí la relación reflejada es “usa una”(uses a). En ella la superclase no es la propietaria de las instancias de la subclase, por tanto si destruimos la superclase las subclases no son destruidas. Se representa de la misma forma que la composición sustituyendo el diamante negro por uno blanco.

Dependencia. Indica que el recurso dependiente necesita otros recursos independientes. Un elemento dependiente podría demandar cambios en caso de que el elemento independiente cambie. La representación gráfica es una linea punteada con una flecha simple que apunta desde el elemento dependiente al independiente.

Interfaces. En notación UML una interface se representa de igual forma que una clase pero colocando un stereotipo “interface” en lo alto de la caja como una forma de diferenciarla. Puedes denotar graficamente que una clase implementa una interface dibujando una linea punteada que empiece en la clase y termine en la interface con una flecha blanca.

Modificadores de Accesibilidad. Los modificadores “public” y “private” para miembros de una clase pueden ser facilmente denotados con los simbolos “+” y “-“ respectivamente. Como en ActionScript no existe el modificador de accesibilidad por defecto (como por ejemplo en Java), si no escribes ningún simbolo se interpreta como si se hubiese escrito el modificador “public”.

Puedes ver en la figura 2 un diagrama más detallado de una clase típica, que muestra como colocar variables y métodos miembro con sus modificadores de accesibilidad respectivos.

Detalle de una clase

Un ejemplo de diagrama UML.

La figura 3 es una ejemplo construido para mostrarte los conceptos antes mencionados.

Detalle de una clase

En dicho ejemplo tenemos un paquete “ui” que guarda todas las clases relacionas con alguna arquitectura de interface de usuario imaginaria.

El ejemplo está focalizado en una clase Window que extiende la clase MovieClip para conseguir toda la funcionalidad necesaria para desplegar un componente de ventanas en la pantalla correctamente. En este punto podrías considerar el usar el Framework de componentes v2 que Macromedia a creado para Flash. En dicho caso deberías extender de la clase UIComponent Class (que hereda de UIOBject y esta última finalmente de MovieClip).

Window implementa la interface IStackable. Podrías precisar más el diagrama y dar el método o métodos que debes implementar en Window (íƒÂ¯¿í‚½que te parece un metodo -moveToTop():Void para manejar el orden de visibilidad, en la pila z-order, de las instancias de las ventanas?, el simbolo “-“ da a entender que su implementación y uso debe ser interno a la clase).

Window tiene una relación de composicion con la clase ToolBar. El diagrama no dice que “una ventana tiene una(y solo una) toolbar”. ToolBar tiene uno o más IconButtons que extienden o heredan de la clase BasicButton. Si destruyes una ventana entonces la toolbar y los botones dentro de esta son destruidos de la misma forma. La relación de composicion retroalimentada en la clase ventana nos viene a decir que una ventana podría comportarse como un contenedor y crear otras ventanas dentro de ella.

Hay otro paquete llamado “os” que contiene las clases que podriamos relacionar con un sistema operativo (operating system). La relación de dependencia (“imports”) nos dice que el paquete os depende del paquete ui y que los cambios en este deben ser tomados en consideración en el otro. El OsModule soporta solo un StageController que agrega cero o más Windows. El StageController usa las ventanas para dar soporte al OsModule acerca de cosas relacionadas con las ventanas. Las ventanas no son parte del StageController y si lo destruyes las ventanas no tienen porque saber nada de esto.

Algunos Links utiles.

Este artículo puede ser usado como un punto de introducción a UML aplicado a Flash. Ahora os dejo unos cuantos links desde los cuales puedes seguir mejorando tu conocimiento de esta poderosa herramienta para desarrollar:

  • uml.org. La página de inicio de UML(Unified Modeling Languaje).
  • gmodeler. La increible aplicación escrita por Grant Skinner. Puedes usarla para crear tus propios diagramas y crear el esqueleto de tus clases. Una segunda versión está en desarrollo.

6 Comentarios

  1. Hola Carlos me alegro de encontrar justo loque buscaba. Un trabajo muy interesante.
    Pero necesito con urgencia algo relacionado al uso de UML aplicado a un software educativo realizado en Flash.
    Té agradeseria que me envies alguna pagina ó tutorial con relación ala pregunta.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *