Enjoy A New Student Discount All 55,000 Courses on sale for Only $12.99

Ends in 05h 23m 49s

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.

  • Diagrama de casos de uso:Son útiles para hablar con los futuros usuarios del sistema, y con el cliente, y resultan útiles para determinar las características necesarias que tendrá el sistema. En otras palabras, los diagramas de casos de uso describen qué es lo que debe hacer el sistema, pero no cómo.
  • Diagrama de clases: muestran las diferentes clases que componen un sistema y cómo se relacionan unas con otras. Se trata de un diagrama estático, ya que indica la relación entre clases, pero no el como se realiza esa relación.
  • Diagramas de secuencia: Los diagramas de secuencia describen las relaciones entre objetos, refiriendo los mensajes que se intercambian, y definen el orden y el momento en que se envían los mensajes a los objetos.
  • Diagramas de colaboración: Los diagramas de colaboración son una variante de los de secuencia; mientras que en los de secuencia se detalle el orden de los mensajes, en la de colaboración, se detalla la forma en la que se generan esos mensajes.
  • Diagrama de estado: Define cada uno de los estados por los que puede pasar un componente y los eventos que provocan los cambios
  • Diagrama de actividad: Asociados a una clase o a un caso de uso, define cada una de las actividades que pueden ocurrir en un componente
  • Diagramas de componentes: Los componentes representan todos los tipos de elementos de software que pueden participar en un sistema. Pueden ser Archivos binarios, de texto, paquetes, bibliotecas o ejecutables. En el diagrama, establecemos la relación y dependencia  entre ellos. Podríamos considerar que el componente es cada uno de los métodos de las clases…
  • Diagramas de implementación: o modelo físico. Muestra la estructura del código (Diagrama de componentes) y la estructura del sistema en ejecución (Diagrama de ejecución).
  • Diagramas de relación de entidad: Muestran el diseño conceptual de las aplicaciones de bases de datos. Realmente, se trata de una extensión pensada para diagramar base de datos.

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

UML. Paquetizando nuestra aplicacion

este diagrama nos ha permitido fraccionar los procesos en paquetes:

UML representacion de paquete

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:

  • Titulo: Cual es el objetivo
  • Actor: Quien lo desea
  • Escenario: Como se llega a ello

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

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

  • Cada caso de uso está relacionado como mínimo con un actor.
  • Cada caso de uso es un iniciador (es decir, un actor)
  • Cada caso de uso lleva a un resultado relevante (un resultado con «valor intrínseco»)

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

UML Imagenes 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.UML - Clase

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:

UML simbolo 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.

UML-Asociaciones

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.

32 comentarios

  1. muy buenos sus artículos, a pesar de que en la web hay miles de tutoriales sobre el tema, definitivamente este y los que lo siguen son recomendables 😀

Deja un comentario

/*Si te ha gustado el artículo
no dudes en compartirlo*/

Facebook
Twitter
LinkedIn

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies

Ver mi IP

Ver ip de mi máquina
tipo valor
Ip: 54.243.2.41
Proxy: 54.243.2.41
Remote host: ec2-54-243-2-41.compute-1.amazonaws.com
Remote port: 41994
** 54.243.2.41