Introducción a UML

La explicación se basará en los diagramas, en lugar de en vistas o anotación, ya que son estos la esencia de UML. Cada diagrama usa la anotación pertinente y la suma de estos diagramas crean las diferentes vistas. Las vistas existentes en UML son:

  • Vista casos de uso: Se forma con los diagramas de casos de uso, colaboración, estados y actividades.
  • Vista de diseño: Se forma con los diagramas de clases, objetos, colaboración, estados y actividades.
  • Vista de procesos: Se forma con los diagramas de la vista de diseño. Recalcando las clases y objetos referentes a procesos.
  • Vista de implementación: Se forma con los diagramas de componentes, colaboración, estados y actividades.
  • Vista de despliegue: Se forma con los diagramas de despligue, interacción, estados y actividades.

Se Dispone de dos tipos diferentes de diagramas los que dan una vista estática del sistema y los que dan una visión dinámica. Los diagramas estaticos son:

  • Diagrama de clases: muestra las clases, interfaces, colaboraciones y sus relaciones. Son los más comunes y dan una vista estática del proyecto.
  • Diagrama de objetos: Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Muestra las instancias y como se relacionan entre ellas. Se da una visión de casos reales.
  • Diagrama de componentes: Muestran la organización de los componentes del sistema. Un componente se corresponde con una o varias clases, interfaces o colaboraciones.
  • Diagrama de despliegue.: Muestra los nodos y sus relaciones. Un nodo es un conjunto de componentes. Se utiliza para reducir la complejidad de los diagramas de clases y componentes de un gran sistema. Sirve como resumen e índice.
  • Diagrama de casos de uso: Muestran los casos de uso, actores y sus relaciones. Muestra quien puede hacer que y relaciones existen entre acciones(casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema.

Lo diagramas dinámicos son:

  • Diagrama de secuencia, Diagrama de colaboración: Muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envían entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin perdida de información, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interacción.
  • Diagrama de estados: muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son útiles en sistemas que reaccionen a eventos.
  • Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.

Como podemos ver el número de diagramas es muy alto, en la mayoría de los casos excesivos, y UML permite definir solo los necesarios, ya que no todos son necesarios en todos los proyectos. En el documento se dará una breve explicación de todos, ampliándose para los más necesarios.

. Diagramas recomendados

Los diagramas a representar dependerán del sistema a desarrollar, para ello se efectuan las siguientes recomendaciones dependiendo del sistema. Estas recomendaciones se deberán adaptar a las características de cada desarrollo, y seguramente será la practica lo que nos diga las cosas que echamos en falta o los diagramas que parecen ser menos necesarios.

  • Aplicación monopuesto
    • Diagrama de casos de uso.
    • Diagrama de clases.
    • Diagrama de interacción.
  • Aplicación monopuesto, con entrada de eventos:
    • Añadir: Diagrama de estados.
  • Aplicación cliente servidor:
    • Añadir: Diagrama de despliegue y diagrama de componentes, dependiendo de la complejidad.
  • Aplicación compleja distribuida:
    • Todos.

Así tenemos que para una aplicación sencilla debemos realizar entre tres y seis tipos de diagramas, y para una aplicación compleja unos nueve tipos. ¿Es esto demasiado trabajo? En un principio no lo parece, ya que el tiempo dedicado a la realización de los diagramas es proporcional al tamaño del producto a realizar, no entraremos en la discusión de que el tiempo de diseño no es tiempo perdido si no ganado. Para la mayoría de los casos tendremos suficiente con tres o cuatro diagramas. Debemos pensar que UML esta pensado para el modelado tanto de pequeños sistemas como de sistemas complejos, y debemos tener en cuenta que los sistemas complejos pueden estar compuestos por millones de líneas de código y ser realizados por equipos de centenares de programadores. Así que no debemos preocuparnos, el mayor de nuestros proyectos, desde el punto de vista de UML no deja de ser un proyecto mediano tirando a pequeño.

COMPARTE ESTE ARTÍCULO

ENVIAR A UN AMIGO
COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN GOOGLE +
HAY 1 COMENTARIOS
  • Anónimo dijo:

    OScar me puedes facilitar ese tutorial en un archivo descargable o zip o enviarmelo en word a mi correo [email protected] Gracias,

Conéctate o Regístrate para dejar tu comentario.