Porque es importante UML ?

Hoy en da, UML ("Unified Modeling Language") esta consolidado como el lenguaje estndar en el anlisis y diseo de sistemas de computo. Mediante UML es posible establecer la serie de requerimientos y estructuras necesarias para plasmar un sistema de software previo al proceso intensivo de escribir cdigo. En otros trminos, as como en la construccin de un edificio se realizan planos previo a su construccin, en Software se deben realizar diseos en UML previa codificacin de un sistema, ahora bien, aunque UML es un lenguaje, ste posee ms caractersticas visuales que programticas, mismas que facilitan a integrantes de un equipo multidisciplinario participar e intercomunicarse fcilmente, estos integrantes siendo los analistas, diseadores, especialistas de rea y desde luego los programadores. Complejidad / Objetos Entre ms complejo es el sistema que se desea crear ms beneficios presenta el uso de UML ("Unified Modeling Language"), las razones de esto son evidentes, sin embargo, existen dos puntos claves : El primero se debe a que mediante un plano/visin global resulta ms fcil detectar las dependencias y dificultades implcitas del sistema, y la segunda razn radica en que los cambios en una etapa inicial (Anlisis) resultan ms fciles de realizar que en una etapa final de un sistema como lo seria la fase intensiva de codificacin. Puesto que UML es empleado en el anlisis para sistemas de mediana-alta complejidad, era de esperarse que su base radica en otro paradigma empleado en diseos de sistemas de alto nivel que es la orientacin a objetos, por lo que para trabajar en UML puede ser considerado un pre-requisito tener experiencia en un lenguaje orientado a objetos.

Hoy en da, entre los lenguajes orientados a objetos ms utilizados se encuentran Java y C#, adems de otros ms antiguos como C++ y SmallTalk, aunque el programar en todos estos lenguajes requiere experiencia previa sobre la sintaxis y bloques especficos, el paradigma empleado en todos ellos es el mismo : Objetos. Lo anterior permite que un anlisis en UML sea realizado independiente del lenguaje en el que finalmente sea implementando el Sistema (Java,C#,C++,SmallTalk), misma caracterstica que permite a personal no familiarizado en lenguajes de programacin participen en el anlisis y diseo de un sistema. Conceptos / Diagramas Entre los conceptos fundamentales de orientacin a objetos se encuentran los siguientes :

Un modelo es una abstraccin del problema que se intenta

resolver.

Un dominio es el mundo de donde proviene el problema . Un modelo consiste de objetos que interactan entre s

envindose mensajes.

Cada objeto posee caractersticas propias (atributos) y

operaciones que puede realizar (mtodos); las valores asignados a un objeto en determinado momento determinan su estado.

Una clase es un molde para describir un objeto que agrupa

caractersticas (atributos) y comportamientos (mtodos).

Los objetos son instancias de Clases.

A continuacin se enumeran los 9 diagramas que forman la base de UML, y dictan la manera en que es diseado un sistema :

Uso-Caso

De Estado (Statechart)

Clases Objetos Secuencia Colaboracin

Actividad Componentes Ejecucin (Deployment)

El uso y diseo de estos diagramas es tema del resto de esta guia para UML.

Definicin y Usos Un diagrama Uso-Caso describe lo que hace un sistema desde el punto de vista de un observador externo, debido a esto, un diagrama de este tipo generalmente es de los ms sencillos de interpretar en UML, ya que su razn de ser se concentra en un Que hace el sistema, a diferencia de otros diagramas UML que intentan dar respuesta a un Como logra su comportamiento el sistema. Un Uso-Caso esta muy relacionado con lo que pudiera ser considerado un escenario en el sistema, esto es, lo que ocurre cuando alguien interacta con el sistema: "Acude un mesero a colocar la orden, la orden es tomada por el cocinero, y posteriormente se abona a la cuenta del cliente el cargo". Un Uso-Caso es empleado con ms frecuencia en alguna de las siguientes etapas :

Determinacin de Requerimientos: Por lo general nuevos

requerimientos de sistema generan nuevos usos-casos, conforme es analizado y diseado el sistema.

Comunicacin con el Cliente: Debido a la sencillez de este tipo

de diagramas, son fciles de emplear para comunicarse con el cliente final del proyecto.

Generacin de pruebas de Sistemas: A travs de los diagramas

uso-caso se pueden generar una serie de pruebas de sistema. En la siguiente seccin se describen los diversos elementos que componen un diagrama Uso-Caso. Composicin

Actor: Un actor representa quien o que inicia una accin dentro

del sistema, en otras palabras, es simplemente un rol que es llevado acabo por una persona o cosa. Un Actor en un diagrama Uso-Caso es representado por una figura en forma de persona.

Uso-Caso: El uso-caso en s es representado por un ovalo que

describe la funcionalidad a grosso modo que se requiere por el sistema.

Comunicacin: Este elemento representa la relacin que

existe entre un Uso-Caso y un Actor, dicho elemento es representado simplemente por una linea recta que se extiende de la figura del actor hacia el ovalo del uso-caso.

Limite de Sistema (System Boundry): Empleado para

delimitar los limites del sistema, y representado por un rectngulo con color de fondo distintivo.

Generalizacin : Una generalizacin indica que un uso-caso

(ovalo) es un caso especial de otro caso, en otros trminos, representa una relacin padre-hijo, donde el hijo puede ser suplido directamente por el padre en cualquier momento. Este elemento es representado por una linea con flecha que se extiende del uso-caso hijo hacia el uso caso padre (general).

Inclusin : Una inclusin es utilizada para indicar que un uso-

caso (ovalo) depende de otro caso, dicho de otra manera, significa que la funcionalidad de determinado caso se requiere para realizar las tareas de otro. Este elemento es representado

por una linea punteada con flecha y comentario <<include>> que se extiende del uso-caso base hacia el uso caso de inclusin.

Extensin : Una extensin representa una variacin de un uso-

caso a otro, aunque similar a una generalizacin, una extensin representa una dependencia especifica, mientras una generalizacin no implica que los usos-casos dependen uno del otro. Este elemento es representado por una linea punteada con flecha y comentario <<extend>> que origina del uso-caso base hacia el uso caso de extensin. Ilustracin

DIAGRAMAS DE ACTIVIDAD Definicin y Usos

Un diagrama de Actividad demuestra la serie de actividades que deben ser realizadas en un uso-caso, as como las distintas rutas que pueden irse desencadenando en el uso-caso. Es importante recalcar que aunque un diagrama de actividad es muy similar en definicin a un diagrama de flujo (tipicamente asociado en el diseo de Software), estos no son lo mismo. Un diagrama de actividad es utilizado en conjuncin de un diagrama uso-caso para auxiliar a los miembros del equipo de desarrollo a entender como es utilizado el sistema y como reacciona en determinados eventos.Lo anterior, en contraste con un diagrama de flujo que ayuda a un programador a desarrollar codigo a travs de una descripcin lgica de un proceso. Se pudiera considerar que un diagrama de actividad describe el problema, mientras un diagrama de flujo describe la solucin. En la siguiente seccin se describen los diversos elementos que componen un diagrama de Actividad. Composicin

Inicio: El inicio de un diagrama de actividad es representado

por un crculo de color negro slido.

Actividad : Una actividad representa la accin que ser

realizada por el sistema la cual es representada dentro de un ovalo.

Transicin: Una transicin ocurre cuando se lleva acabo el

cambio de una actividad a otra, la transicin es representada simplemente por una linea con una flecha en su terminacin para indicar direccin.

Ramificacin (Branch) : Una ramificacin ocurre cuando existe la posiblidad que ocurra ms de una transicin (resultado) al

terminar determinada actividad.Este elemento es representado a travs de un rombo.

Unin (Merge) : Una unin ocurre al fusionar dos o ms

transiciones en una sola transicin o actividad.Este elemento tambin es representado a travs de un rombo.

Expresiones Resguardadas (Guard Expressions) : Una

expresi resguardada es utilizada para indicar una descripcin explicita acerca de una transicin. Este tipo de expresin es reprsentada mediante corchetes ([...] y es colocada sobre la linea de transicin.

Fork : Un fork representa una necesidad de ramificar una

transicin en ms de una posibilidad. Aunque similar a una ramificacin (Branch) la diferencia radica en que un fork representa ms de una ramificacin obligada, esto es, la actividad debe proceder por ambos o ms caminos, mientras que una ramificacin (Branch) representa una transicin u otra para la actividad (como una condicional). Un fork es representado por una linea negra solida, perpendicualar a las lineas de transicin .

Join : Una join ocurre al fusionar dos o ms transiciones

provenientes de un fork, y es empleado para dichas transiciones en una sola,tal y como ocurria antes de un fork .Un fork es representado por una linea negra solida, perpendicualar a las lineas de transicin .

Fin : El fin de un diagrama de actividad es representado por un crculo, con otro circulo concentrico de color negro slido.

Canales (Swimlanes) : En determinadas ocasiones ocurre

que un diagrama de actividad se expanda a lo largo de ms de un entidad o actor, cuando esto ocurre el diagrama de actividad es

particionada en canales (swimlines), donde cada canal representa la entidad o actor que esta llevando acabo la actividad.

Diagramas de Clases : Definicin y Usos Un diagrama de Clases representa las clases que sern utilizadas dentro del sistema y las relaciones que existen entre ellas. Los diagramas de Clases por definicin son estticos, esto es, representan que partes interactan entre s, no lo que ocurre cuando. Ilustracin