UML Capítulo 2: Conceptos Básicos I

¡Hola de nuevo internauta!,

    A continuación vamos a introducir unos cuantos conceptos de UML ya que es necesario tener una idea fundamental de los mismos puesto que los iremos ampliando en futuras entradas. Para los que sepan de que va el tema, tomaros un merecido descanso. Para los que quieran seguir leyendo avisaros que serán varias entradas con los distintos tipos de diagramas que existen. No quiero hacer los artículos de introducción a UML muy pesados, ¡ya habrá tiempo de escribir líneas y ejemplos en las futuras entradas!.

Los tipos de diagramas que veremos en esta primera entrada son los siguientes: Diagrama de clases, diagrama de estructura interna, diagrama de colaboración, diagrama de componentes y diagrama de casos de uso.

Aviso a navegantes: ¡Pero esto no son los diagramas!, dirán los más versados en el tema; paciencia; ya lo sé. Este artículo intenta dar una idea conceptual sin usar las notaciones usadas en UML que ya explicaremos más adelante. Además que para no resultar pesado, y que sea liviana su lectura, lo dividiré en varias entradas(que lo que quiero es que también sea divertido y no un pesado).



Diagramas

Mediante los diagramas se intentan reflejar relaciones y operaciones en un sistema. Para ello UML cuenta con los siguientes tipos de diagramas(ojo, es un resumen, más bien un "resumito" chiquito):

• Diagrama de clases: Visualiza las relaciones(asociación, generalización y dependencia)entre las clases que forman el sistema describiendo así su estructura.
Su representación gráfica es un rectángulo con una lista de atributos y operaciones mostradas en compartimentos independientes como aparece en el siguiente ejemplo.




¿Qué nos dice este diagrama?. Que el sistema tiene tres clases: persona, película y productora; sus atributos(nombre:String, por ejemplo); sus relaciones: una persona puede estar en una o varias películas, una película puede tener una o varias personas e idem para la relación con las productoras; y los métodos de cada clase para grabar datos(los que empiezan por set) cómo para obtener los datos(los que empiezan por get).

• Diagrama de estructura interna: Muestra la estructura interna de una clase y como se conecta esta con el mundo exterior.


Si observamos con atención el detalle del diagrama podemos inferir lo siguiente: la clase Persona expone un interfaz(IPersona) que llama al método setPersona(para el alta) y que este a su vez recupera si dicha persona existe(no nos preocupamos que pasa si existe dicha persona o cómo se realiza la comunicación) y una base de datos de Personas. Cada uno de ellos interactúa con el exterior mediante un puerto(representado en el diagrama por el cuadrado) siendo el expuesto públicamente el de alta(alta:setPersona) y quedando el resto encapsulado al resto del sistema.

• Diagrama de colaboración: Representa cómo trabajan juntos los objetos para conseguir fin. Para ello en este diagrama se implementa las asociaciones del diagrama de clases mediante el paso de mensajes de objeto a objeto de manera secuencial.

¿Y esto que representa?.Vamos como interactúan cuatro componentes que dan la funcionalidad al sistema GestionBaseDeDatos: persona, productora, película y la aplicación gestión. Con ello queremos representar la sinergia entre todos los componentes que permitirá al usuario explotar el sistema del cual forman parte.

• Diagrama de componentes: Representa los distintos componentes(archivos, paquetes, etc) del sistema y sus dependencias lo que nos ayuda a valorar el impacto de un cambio producido. En el gráfico de ejemplo los círculos representan interfaces proporcionados(los servicios ofrecidos) por el componente o clase y el semicírculo representa interfaces obligatorias(los servicios que necesita) el componente o clase.

¿Y qué es lo que tenemos aquí?, pues nada más y nada menos que la representación de una parte del sistema de GestionBaseDeDatos vista en el punto anterior, particularmente la de la clase película(representada en el primer punto Diagrama de Clases). Podemos ver como el usuario puede interactuar con esta parte del sistema mediante la interfaz, InterfazPelicula, y como esta internamente llama a otras como GestorPeliculas y GestorActores.
¿Os habéis fijado que los métodos usados son los mismos que los indicados en el diagrama de clases?(estoy seguro que sí pero lo dejo caer igualmente). Faltaría implementar los correspondientes a la productora pero me he levantado vago ;). Además de reflejar también la colaboración entre el objeto película y la aplicación Gestión , ¿será por eso que las interfaces que ofrecen los métodos empiezan por Gestor? ;).

• Diagrama de casos de uso: Con este diagrama se pretende modelar la funcionalidad de un sistema tal y como lo perciben los agentes externos o actores, enumerarlos y mostrar que actores participan de cada caso de uso. ¡Ojo no confundamos este tipo de diagrama con los casos de uso!, estos últimos son más detallados. Aunque es cierto que ambos conceptos están relacionados.

En este Diagrama de casos de uso hemos representado lo indicado en el punto anterior(Diagrama de componentes) correspondiente al modelado de la relación entre el usuario(actor y que gráficamente se representa con el muñeco) y la interfaz, InterfazPelicula. De esta manera podemos ver de una manera gráfica y abstracta como un usuario a través de InterfazPelicula puede interactuar con el sistema mediante otros casos de uso(no expuestos públicamente y por lo tanto encapsulados), en este ejemplo, GestorDePelicula y GestorDeActores.

Y hasta aquí la entrada de hoy. Espero no haber sido muy pesado y que os hayan quedado claro los conceptos.

¡Gracias por leerme!.