Introducción a UML

Tengan un buen día. He notado que muchos de nosotros, como desarrolladores de software (de escritorio o web; en C++, Borland, ALGOL, Cobol, RPG, Simula, B, C, C#, etc.), obviamos muchas cosas en el amplio mundo del desarrollo, cosas de tipo teórico (metodologías, planeación, modelado, etc.) Que son bastante importantes pues nos ayudan a:

-Elaborar software de calidad

-Trabajar de manera adecuada dentro de un equipo de trabajo

-Organización en un equipo de trabajo

-Y muchas otras más

Para ello nos auxiliamos de metodologías tales como el análisis de sistemas, la ingeniería del software, etc. Pero a lo que me quiero enfocar es en una herramienta que ayuda en el desarrollo de un proyecto. No servirá de mucho si debemos desarrollar un proyecto de software pequeño, que podemos hacer nosotros solos en poco tiempo, para lo cual basta con planear el proyecto en una hoja de papel solo para ver “que va a llevar”. Pero este no es el caso cuando se está en un equipo de trabajo de desarrolladores con un proyecto de mediana-alta dificultad, de bastante tiempo de trabajo, en donde los diferentes inconvenientes son:

-Comunicar las ideas que se tienen de la arquitectura del software

-Designar adecuadamente y sin confusión alguna que va a hacer cada uno

Porque si estamos con un equipo de trabajo de desarrolladores y nos ha tocado la labor de de diseñar el sistema, no podemos hacer algo como ponernos a escribir en un trozo de papel lo que consideramos debe llevar el software, pues será informal, no entendible por todos y desorganizado.

Para ello está una herramienta, mejor dicho, un lenguaje, que es el UML (Unified Modeling Language ó Lenguaje de Modelado Unificado) el cual nos sirve para hacer una representación del sistema previa a su codificación y en la fase de análisis, ya que nos permite representar la funcionalidad del software, es decir, como el usuario va a interactuar con el software, que le devolverá el software, los procesos que van a realizarse, y también a nivel de código puede hacerse un diagrama del software determinando las clases que va a llevar, los métodos que contendrá cada clase, los módulos, etc. (para ello se debe aplicar la programación orientada a objetos) a fin de crear diagramas que representen de manera adecuada la arquitectura del software, que pueda ser entendida por todos los miembros de un equipo de trabajo y que facilite la asignación de responsabilidades.

Diagramas de caso (Case diagrams)

Cuando iniciamos un proyecto de desarrollo de software, el primer paso (y uno de los más importantes) es la determinación de requerimientos del usuario final, lo cual se logra mediante entrevistas, observación, revisión de documentación, etc. Y luego de ello, algo que deberíamos de hacer es mostrar al usuario como es que el va a trabajar con el software, es decir, presentar el software desde la perspectiva del usuario, esto lo logramos haciendo uso de los diagramas de caso, y un ejemplo es el siguiente:

Digamos que vamos a hacer un sitio web acerca de artículos de informática (programación, bases de datos, diseño gráfico, etc.) parecido a sitios como www.maestrosdelweb.com, www.data2max.com, etc. Ya sabemos que funcionalidad va a tener el sitio, y queremos representarla a, el gerente o algo asi, entonces utilizamos un diagrama de casos para representarlo como el que aparece a continuación.

NOTA: Haz click en las imagenes para verlas bien, pues como son algo grandes los diagramas, no los podia mostrar completamente aqui.

Tan sencillo, si, asi es un diagrama de casos. En este diagrama, al muñequito que representa al usuario, es llamado el actor, mientras que la acción encerrada en el óvalo es el caso.Pero, imaginémonos que deseamos ser mas específicos con las acciones que podrá realizar el usuario, pues simplemente detallamos mejor dichas acciones de la siguiente manera.

También sabemos que debe haber un administrador para el sitio web, y este también debe realizar otras acciones o casos tales como crear artículos, eliminar artículos, subir archivos al servidor, administrar el foro. Simplemente hacemos otro diagrama de caso expresando que el actor es el administrador.

También sabemos que el administrador debe realizar ciertas tareas administrativas que son las que permiten que solo el administrador (y no al usuario normal obviamente) pueda llevar a cabo los casos que están en el diagrama anterior, estas tareas son acciones independientes que deben realizarse previamente a las acciones administrativas, y estas acciones son llamadas en UML casos de uso administrativo, y se representan dentro del diagrama de igual modo que los casos normales, solo que se concatenan a los casos normales con una línea punteada y con la palabra include, de la siguiente manera.

Y, por último en esta introducción a UML, especificar que pueden incluirse varios actores en un diagrama de casos y que hay acciones o casos que pueden ser llevados a cabo por mas de un usuario de la siguiente manera.

Con esto finalizo lo que es una introducción a UML, debido a que hay más tipos de diagramas, los cuales voy a tratar en otro post.