lang="es"> Introduccion al UML
Recursos para formacion

Introduccion al UML

El UML (Lenguaje unificado de modelado o Unified Modeling Language)  establece una notación estándar y semánticas esenciales para el modelado de un sistema orientado a objetos, UML no propone un proceso o método estándar para desarrollar un sistema. Y aunque solo define la notación, es importante que lo conozcamos ya que ha evolucionado hasta convertirse en un estándar manejado por la mayoría de herramientas «Case».

Así como Java o PHP son lenguajes de programación que no definen como solucionar el problema, si no como escribir dicha solución, UML hace lo mismo con el modelado; no te va a decir como encarar el análisis; para ello hay otras herramientas como Catalysis, Objetory, OMT, o Fusion; solo establecerá como tienes que representar tu solución sobre el papel para que la mayoría de personas que trabajan en OOP lo entiendan.

UML nos ha de indicar que elementos (imágenes) debemos usar al realizar nuestros diagramas, y aunque tiene definidos muchos tipos de diagramas.

Supongo que ya os vais dando cuenta que para poder definir un desarrollo necesitamos todos los diagramas, y a demás de una forma muy detallada, pero…nosotros vamos a comentar unos pocos, ya que el objetivo del articulo no es conseguir un conocimiento profundo del UML, sino darte las herramientas mínimas imprescindibles para que puedas integrarte en cualquier equipo que esté utilizando esta herramienta.

De esta forma también esquivamos el riesgo de provocar que los arboles no os dejen ver el bosque…que un conocimiento extenso del UML no os haga intentar desarrollar diagramas tan completos que no los acabéis nunca.

Paquetes

Para poder encarar el análisis de una aplicación, la mejor opción es dividirla en áreas manejables; UML introduce la noción de un paquete como el ítem universal para agrupar elementos, permitiendo a los modeladores subdividir y categorizar sistemas.

La aplicación que hemos comentado aquí, la podemos paquetizar según este Diagrama

este diagrama nos ha permitido fraccionar los procesos en paquetes:

Si lo consideramos necesario, podemos seguir creando paquetes para dividir cada uno de los paquetes que hemos definido en este paso, hasta conseguir unidades fáciles de entender y analizar, ademas de autónoma.

Diagrama de casos de uso

Los casos de uso aunque no son un modelado orientado a objetos, si no una forma de plasmar el comportamiento actual o deseado de la aplicación, nos permite modelar los requisitos del sistema desde la perspectiva del usuario y es una herramienta que nos va a ayudar en el dialogo con nuestro cliente.

Un caso de uso describe, —desde el punto de vista de los actores—, un grupo de actividades de un sistema que produce un resultado concreto y tangible. Para ello tiene tres componentes:

Según detallamos en este artículo, podríamos presentar una primera visión de casos de uso así:

Un caso de uso, presenta los requerimientos desde el punto de vista de los actores, y tenemos que tener en cuenta:

los actores se dibujan como muñecos de palo, y las actividades del sistema, como una Elipse, y si necesitamos detallar el escenario, podemos utilizar un rectángulo en el que escribiremos el paso a paso necesario para realizar ese caso de uso

Un actor es una entidad de fuera del sistema que interacciona con el sistema iniciando en un caso de uso. Los actores pueden ser  usuarios del sistema u otros ordenadores o eventos externos.

Los actores primarios se dibujan normalmente a la izquierda del sistema, y son los que inician la acción; los actores secundarios de dibujan a la derecha del sistemas y son invocados por la acción.

Los actores no representan a personas físicas o a sistemas, sino su rol. Esto significa que cuando una persona interactúa con el sistema de diferentes maneras, estará representado por varios actores. Por ejemplo, una persona que proporciona servicios de atención telefónica a clientes y realiza pedidos para los clientes estaría representada por un actor «equipo de soporte» y por otro actor «representante de ventas».

Realmente, los casos de uso los tendríamos que estudiar dentro de los paquetes, entonces, los casos de uso nos pueden mostrar una posible nueva paquetizacion que llevara a nuevos casos de usos mas detallado, hasta llegar al nivel mas bajo.

Diagrama de clases

Podemos verlo como el mas importante para el análisis y diseño del sistema ƒ Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia.ƒ La definición de clase incluye definiciones para atributos y operaciones.

Los diagramas de clases muestran las diferentes clases que componen un sistema y cómo se relacionan unas con otras. Se dice que los diagramas de clases son diagramas «estáticos» porque muestran las clases, junto con sus métodos y atributos, así como las relaciones estáticas entre ellas: qué clases «conocen» a qué otras clases o qué clases «son parte» de otras clases, pero no muestran los métodos mediante los que se invocan entre ellas.

Una clase define los atributos y los métodos de una serie de objetos. Todos los objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y los mismos de atributos (cada objetos tiene el suyo propio). En ocasiones se utiliza el término «tipo» en lugar de clase, pero recuerde que no son lo mismo, y que el término tipo tiene un significado más general.

En el diagrama, las clases están representadas por rectángulos, con el nombre de la clase, y también pueden mostrar atributos y operaciones de la clase en otros dos «compartimentos» dentro del rectángulo.

en la imagen precedente, estamos definiendo la clase «Persona» y definimos tres atributos: nombre, direccion y correoElectronico, y también tres comportamientos: crear(), borrar(), y enviarMensaje.

En UML, los atributos se describen al menos con su nombre, y también se puede indicar su tipo, valor inicial y otras propiedades.

Las operaciones (métodos) también se describen al menos con su nombre, y pueden mostrar sus parámetros y valores de retorno

En el primer carácter de métodos y atributos, podemos añadir una indicación de la visibilidad

  • + Indica atributo/método público
  • # Indica atributo/método protegido
  • - Indica atributo/método privado

Asociaciones

En el diagrama de clases podemos especificar como se relacionan las distintas clases. Las formas principales son:

Herencia:

Las generalizaciones se representan por medio de una línea que conecta las dos clases, con una flecha en el lado de la clase base. Con la herencia conseguimos recibir todas las características de la clase padre o Superclase (Generalización).

Asociación

Las asociaciones son los mecanismos que permite a los objetos comunicarse entre sí y representa una relación entre clases, indicando la forma en la que colaboran.

Cada extremo de la asociación también tiene un valor de multiplicidad, que indica cuántos objetos de ese lado de la asociación están relacionados con un objeto del extremo contrario.

Salir de la versión móvil