Diagrama de casos de uso

En este apartado explico para que sirve el diagrama de casos de uso.

Los diagramas de casos de uso se agrupan dentro de la clasificación de diagramas estáticos de UML, ya que realizan un estudio del comportamiento del sistema desde el punto de vista del usuario.

En definitiva, los casos de uso no son más que el estudio de los usos que se le va a dar a algo. Enfocado al mundo del software serían un estudio de los requisitos que queremos que nuestra aplicación cumpla, entendiendo por requitos las funciones que va a tener nuestra aplicación una vez desarrollada.

Para entender esto un poco mejor imaginemos que nos vamos a comprar un automóvil. Bien, lo más lógico es que cuando lo hagamos pensemos en funciones que necesitemos que tenga ese automovil, de manera que nuestra compra satisfaga nuestras necesidades. De esta forma nos preguntaremos cosas como las siguientes:

• ¿Lo usaremos para 2 ó para más personas?
• ¿Que pensamos cargar en el maletero?
• ¿Lo usaremos en viajes largos o cortos?
• ¿Necesitamos que sea rápido?
• ¿Queremos gasolina o diesel?

Con esto realizamos un estidio de las funciones que queremos que nuestro automóvil tenga, desechando aquéllas que no utilizaremos o bien que no nos parezcan interesantes. Esto sería realizar un estudio de casos de uso del automóvil que vamos a adquirir. Siguiendo dicho estudio la compra de nuestro futuro automóvil deberia ser la más acertada.

Como se ha podido ver, los casos de uso no se enfocan hacia cómo se van a hacer realidad nuestras necesidades sino hacia cuáles son, es decir, no se interesan por la implementación(como se hace dicha función) sino en las funciones que se necesitan.

Puesto que los casos de uso se utilizan para capturar los requisitos, los diagramas de caso de uso serán empleados durante la fase de análisis del sistema.

En los diagramas de casos de uso encontraremos:

• Actores, se representan mediante un muñeco y son los que realizan o demandan las tareas (el uso).
• Casos de uso, representan las funciones(uso).
• Relaciones de dependencia, generalización y asociación entre ellos. Se representan con lineas que conectan los casos de uso o actores.

Generalmente los actores permanecen fuera del sistema y los casos de uso están contenidos en él. Para representar cuáles son los límites del sistema se representa un rectángulo.

Imaginemos que queremos implementar una máquina expendedora de chocolatinas. En este sistema encontramos gente que quiere comprar una chocolatina, quien recarga la máquina de chocolatinas y quien retira el dinero de la máquina. Una solución de este ejemplo sería el siguiente modelo de casos de uso.

En otro articulo explicare los distintos tipos de asociaciones que existen en el lenguaje UML.

UML, orientación de objetos

UML es un lenguaje para modelar aplicaciones o sistemas.

Para ello introduce una serie de notaciones y diagramas estándar, y describe una semántica esencial de lo que estos diagramas y símbolos significan.

UML no parte de cero sino que es una notación que se basa en otras notaciones ya existentes, provenientes de:
• Modelado Orientado a Objetos,
• Modelado de Datos,
• Modelado de Componentes,
• Modelado de Flujo de Trabajo.

Las características principales de este lenguaje se pueden englobar en las siguientes:
• Aporta una notación estándar (un lenguaje) orientada a objetos, para el desarrollo de aplicaciones o sistemas informáticos y que es aceptada por todas las grandes empresas del momento.
• No es un proceso de desarrollo, sino un lenguaje de modelado, es decir no nos indica cómo tenemos que realizar el desarrollo de un sistema. Este lenguaje puede ser aplicado a cualquier metodología existente.
• Se basa en especificaciones anteriores como son BOOCH, RUMBAUGH Y COAD-YOURDON.
• Permite describir un sistema en diferentes niveles de abstracción, es decir, plasmar la idea desde diferentes puntos de vista, simplificando la complejidad de la misma y sin que se produzca pérdida de información. Esto permite que todas las personas participantes en el desarrollo de la aplicación (usuarios, desarrolladores, analistas, jefes, etc.) puedan comprender sus características ya que mostrará el sistema desde el punto de vista que les interesa a cada uno de ellos.

Divide cada proyecto en un número de diagramas que representan diferentes vistas del proyecto. Estos diagramas juntos son los que representan la arquitectura del proyecto.
UML se puede aplicar tanto a sistemas informáticos como a sistemas que no son informáticos, como pueden ser los flujos de trabajo en una empresa o diseño de la estructura de una organización.

Historia de UML
El desarrollo de UML comenzó en octubre de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation comenzaron a trabajar en la unificación de los lenguajes de modelado Booch y OMT

UML incorpora ideas de otras metodologías desarrolladas por otros autores. Por tanto en el transcurso del estudio de UML, encontraremos cosas que son heredadas de otras metodologías como pueden ser Orientadas a objetos, Modelos de Entidad y Relación, etc.

¿Qué se propone conseguir UML?
Se pretende conseguir a través de UML las siguientes funciones:

• Visualizar: UML permite expresar de una forma gráfica un sistema de forma que otro lo puede entender.
• Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción.
• Construir: A partir de los modelos especificados se pueden construir los sistemas diseñados.
• Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado que pueden servir para su futura revisión.

Modelos UML

Un modelo es una abstracción (una representación o vista) de "algo", que aplicado a nuestro campo puede ser un sistema informático, una aplicación, etc.

En un modelo podemos interpretar los siguientes elementos de construcción:
• Elementos: Los elementos son abstracciones de cosas reales o ficticias (objetos, acciones, etc.)
• Relaciones: relacionan los elementos entre sí.
• Diagramas: Son colecciones de elementos con sus relaciones.

La construcción de un modelo aporta las siguientes ventajas:

Aproximación de lo que será el producto final.
Permite visualizar cómo quedará el resultado.
Divide un problema complejo en varios problemas de menor complejidad y por tanto más fáciles de resolver.

Los diagramas de los que se compone UML son los que se mencionan de una forma superficial a continuación:

Diagrama de casos de Uso. En ellos se captura los requisitos del sistema, es decir, qué funciones va a realizar el sistema, desde el punto de vista de la interacción con el usuario.

Diagramas de clases. Muestran un conjunto de clases, interfaces y sus relaciones. Es el diagrama principal de UML y al que dedicaremos más tiempo. Éste es el diagrama más común a la hora de describir el diseño de los sistemas orientados a objetos.

Diagramas de Objetos. Muestran una serie de objetos (instancias de las clases) y sus relaciones. Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Su representación gráfica sería equivalente a la del diagrama de clases pero más detallado.

Mediante el modelo de casos de uso obtenemos información acerca de las clases, objetos, atributos y operaciones que debemos establecer en los diagramas de clases y objetos.

Diagramas de estado. Se utilizan para analizar los cambios de estado de los objetos. Muestran los estados, eventos, transiciones y actividades de los diferentes objetos. Estos diagramas son útiles en sistemas orientados a eventos.

Diagramas de Actividad. son un caso especial del diagrama de estados, simplifica el diagrama de estados modelando el comportamiento mediante flujos de actividades. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.

Diagramas de Secuencia. capturan la interacción entre los objetos y los mensajes que intercambian entre sí atendiendo al orden temporal de los mismos.

Diagramas de colaboración. igualmente, muestra la interacción entre los objetos resaltando la organización estructural de los objetos en lugar del orden de los mensajes intercambiados.
Diagramas de componentes, muestra la organización y las dependencias entre un conjunto de componentes. Se usan para agrupar clases en componentes o módulos.

Diagramas de Despliegue, muestra los dispositivos que se encuentran en un sistema y su distribución en el mismo. Se utiliza para identificar Sistemas de Cooperación: Durante el proceso de desarrollo el equipo averiguará de qué sistemas dependerá el nuevo sistema y qué otros sistemas dependerán de él.

Los diagramas los vamos a clasificar según el estudio que hacen del comportamiento del sistema. De esta forma podemos agrupar los diagramas en:
• Estáticos, si representan el sistema de forma estática.
• Dinámicos, que por el contrario representan el comportamiento (dinámico) del mismo.
De esta forma tenemos:
• Los diagramas que representan al sistema en su forma estática son:
• De clases,
• De objetos,
• De componentes e
• De implementación.
• Los diagramas que representan cómo se comporta el sistema(dinámica) son:
• De colaboración,
• De estado,
• De actividad y
• De casos de uso.

Relaciones entre clases

Tipos de relaciones que se pueden dar entre clases:

- Unidireccional: en un único sentido.


- Bidireccionales: en ambos sentidos (sin flecha).

Lo normal es que sean bidireccionales.


Relación de asociación:

Cuando se establece una relación entre objetos, en términos de programación orientada a objetos se dice que se produce una asociación.

El papel o rol que juega cada clase en la relación siempre va a indicarse gráficamente en los extremos de la relación.


Multiplicidad de una asociación:

Indicara el grado con el que una clase se asocia a otra, por ejemplo, cuántas conexiones van a existir entre un objeto de la clase A con un objeto de la clase B y viceversa, a esto se le llama “cardinalidad”.

La cardinalidad entre dos clases, al igual que el Rol que la clase juega en la relación, la vamos a representar gráficamente en los extremos de la relación.
Los diferentes tipos de cardinalidad que podemos indicar en una relación son:
• Uno a uno (1,1): un objeto de tipo A se relaciona uno a uno con objetos de tipo B.
• Uno a muchos (1,*): indica que un objeto A puede relacionarse con uno o varios objetos de tipo B.
• Muchos a muchos (*): indica un objeto de tipo A puede relacionarse con varios objetos de tipo B.
• Opcional (0,1): Indica que el objeto de tipo A puede estar o no relacionado con un objeto de tipo B.
• Opcional múltiple (0,*): Otro tipo de cardinalidad opcional pero en este caso se da que un objeto de tipo A puede estar ninguna o muchas veces relacionado con objetos de tipo B.
• Número fijo (n): En este caso indicamos un número de veces concreto que se relaciona un objeto de tipo A con objetos de tipo B.


Grado de una asociación:

Se determina por el número de clases conectadas por la misma asociación. Las asociaciones pueden ser:
- Asociaciones binarias: las que solo relacionan dos clases.
- Asociaciones terciarias: Las que relacionan tres clases.
- Asociaciones n-Anarias: donde se relacionan “n” clases.


Asociaciones Reflexivas:

Son las que relacionan distintos objetos de una misma clase. Un ejemplo:

Los ocupantes de un automóvil. Aquí podemos establecer relaciones entre objetos de la misma clase de la siguiente forma: un ocupante puede ser conductor del automóvil y habrá otros ocupantes que pueden ser pasajeros del automóvil.

Atributos de liga o asociación:

Este tipo de atributos son los que no pertenecen a ninguna de las clases que se asocian sino que son atributos de la asociación que hay entre ellas, es decir son propiedad de la asociación.

Establecemos atributos sobre las relaciones cuando el atributo no pertenece a ninguna de las clases que participan en la relación y sí a la relación.


Relación de agregación:

En este tipo de relaciones el objeto base (el que agrega a otros) utiliza a otros objetos para su funcionamiento. Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye ya que estos pueden existir sin que el objeto base exista.

Un ejemplo de agregación puede ser el siguiente: Una Red de Computadoras se puede considerar un ensamblado, donde las Computadoras son sus componentes.

En esta relación el objeto utilizado es independiente del que lo usa.


Relación de composición:

En este tipo de relación se da a entender que el objeto base se construye a partir de otros objetos incluidos. Es un tipo de relación estática, en donde el tiempo de vida de los objetos incluidos está condicionado por el tiempo de vida del objeto que los incluye, ya que éstos forman parte de él.

Un ejemplo de composición sería: Un Ordenador como ensamblado, donde el microprocesador y el disco duro son sus componentes.
• El microprocesador y el disco duro son partes del Ordenador, y a diferencia de la agregación, no pueden ser compartidos entre distintos Ordenadores a la vez.
• No tiene mucho sentido que el microprocesador y el disco duro existan de manera independiente al ordenador, por lo cual la composición refleja de manera importante, el concepto de propiedad.

Herencia: Generalización y especialización

Las clases con atributos y operaciones comunes se pueden organizar de forma jerárquica, mediante la herencia.

La herencia es una abstracción importante para compartir similitudes entre clases, donde todos los atributos y operaciones comunes a varias clases se pueden compartir por medio de la superclase, también llamada clase base, que es una clase más general.

Un ejemplo: las clases Reptil, Anfibio y Mamífero. Todas estas son subclases de la superclase Animal, de la que derivan. La superclase tendrá una serie de atributos y operaciones comunes a todas las subclases (Reptil, Anfibio y Mamífero), mientras que en las subclases encontraremos atributos y operaciones específicos de cada tipo de animal. Por tanto se puede establecer que las subclases hereden de la superclase, ya que los atributos y operaciones de ésta son comunes a todas ellas.

De todo esto se deduce:
• La superclase generaliza a sus subclases.
• Las subclases especializan a la superclase.
• El proceso de Especialización es inverso al de Generalización.
• Una instancia de una subclase, es también una instancia de su superclase. Esto quiere decir que cuando creamos un objeto de tipo Anfibio, éste contiene la información definida en él y también la heredada de la superclase Animal. Por eso decimos que es una instancia de ambas clases.
Cuando utilizamos la herencia tenemos que tener en cuenta que los nombres de atributos y operaciones deben ser únicos en la jerarquía de herencia.


Relaciones de dependencias:

Representa un tipo de relación muy particular, en la que una clase es instanciada y en la que su instanciación es dependiente de otro objeto/clase.

Es una relación de uso, es decir una clase usa a otra, que la necesita para su cometido. Se representa con una flecha discontinua que va desde la clase utilizadora a la clase utilizada.

Diagramas de clase

- clases

Una clase es una plantilla que define un tipo de objeto.

• Los objetos son instancias de las clases.
• Los objetos no existen hasta el momento de su creación, es decir, en un programa los objetos no existen hasta que el programa se ejecute.
• Las clases se representan mediante un rectángulo, en el que se divide en tres filas:

- Atributos:

• Un atributo representa alguna propiedad o característica de la clase.
• Un tipo de atributo nos indicara la naturaleza que va a poder tomas una variable.
• Los atributos o caracteristicas se pueden clasificar en tres grupos haciendo referencia a su nivel de encapsulación, es decir, el grado de comunicación y visibilidad de ellos con el entorno:

- Publico (public): puede ser visible dentro y fuera de la clase.
- Privado (private): solo es visible dentro de la clase.
- Protegidos (Protected): indica que el atributo no seran visible desde fuera de la clase, pero si dentro de la clase, y accesible por las subclases que las hereden de las clases que lo contienen.

En una herramienta se representan asi:
• Publico (public) (+).
• Privado (Private) (-).
• Protegido(protected) (#).

Reglas de los atributos que se deben de cumplir:

• El nombre de un atributo debe ser único dentro de la clase.
• El nombre de un atributo NO debe tener espacios entre sí.
• Los atributos no tienen ninguna identidad, al contrario que los objetos.
• Los atributos toman valores dentro de un determinado rango.
• Los atributos de una clase no deberían ser manipulados directamente por el resto de objetos.

- Identificadores:

Los identificadores son un tipo de atributo cuya función no va a ser la de reflejar características de la clase en la que se encuentran sino la de identificar unívocamente a la clase una vez que se instancia, es decir, va a identificar a los objetos, diferenciando unos de otros.

Cuando construimos las clases del sistema, los identificadores NO deben ser incluidos como atributos de la clase.

- Una clase estará determinada por un estado y un comportamiento.
- Un objeto estará determinado por un identificador, un estado y un comportamiento.

Características del identificador:
• Es único y global para cada objeto dentro del sistema.
• Es determinado en el momento de la creación del objeto.
• Es independiente de las propiedades del objeto.
• No cambia durante la vida del objeto ni tampoco se reutiliza cuando éste deje de existir.

- Métodos:

Son el conjunto de funcionalidades que describen la naturaleza y el comportamiento que tendrán los objetos de la clase; es decir, las operaciones que van a poder realizar los objetos de esa clase.

Ejemplos:
• Para la clase Puerta podemos tener los siguientes: abrir, cerrar, pintar, etc. Cuando se instancia esta clase y se crea el objeto Puerta, éste puede ejecutar su método abrir y la puerta se abrirá.
• Para la clase Persona: comer, dormir, andar, etc. De la misma forma que el ejemplo anterior un objeto Persona comerá cuando ejecute su método comer.

Reglas de los métodos que hay respetar:

• Los métodos deben ser únicos dentro de una misma clase.

Ejemplo: La clase Persona y Gato pueden tener un método que sea dormir pero no pueden existir dos métodos dormir dentro de una misma clase.

• No se debe utilizar el mismo nombre para métodos que tengan un significado totalmente diferente.

Ejemplo: un método que se llame desplazarse para la clase Persona y para la clase Coche. Este método no debe llamarse igual en ambas clases ya que la manera en que los dos objetos se desplazarán no es la misma y por tanto el método no debe llamarse de la misma forma, porque podría generar confusión. Para corregir esto, la manera adecuada sería llamarlos por ejemplo Caminar para la clase Persona y Circular para la clase Coche.

Los métodos pueden tener argumentos, es decir, una lista de parámetros, cada uno con un tipo y pueden también retornar resultados, cada uno con un tipo.

Al igual que ocurre con los atributos, encontramos tres modos de encapsular los metodos de una clase, es decir, determinar la visibilidad de los metodos de una clase.

• Publico (public) (+).
• Privado (Private) (-).
• Protegido(protected) (#).

Lenguaje UML

UML es un lenguaje para modelar aplicaciones o sistemas.

Para ello introduce una serie de notaciones y diagramas estándar, y describe una semántica esencial de lo que estos diagramas y símbolos significan.

Características principales:

• Aporta una notación estándar (un lenguaje) orientada a objetos.
• No es un proceso de desarrollo, sino un lenguaje de modelado, es decir no nos indica cómo tenemos que realizar el desarrollo de un sistema.
• Se basa en especificaciones anteriores como son BOOCH, RUMBAUGH Y COAD-YOURDON.
• Permite describir un sistema en diferentes niveles de abstracción.
• Divide cada proyecto en un número de diagramas que representan diferentes vistas del proyecto.
• UML se puede aplicar tanto a sistemas informáticos como a sistemas que no son informáticos.

Lo que se pretende a través de UML son las siguientes funciones:

• Visualizar: UML permite expresar de una forma gráfica un sistema de forma que otro lo puede entender.
• Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción.
• Construir: A partir de los modelos especificados se pueden construir los sistemas diseñados.
• Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado que pueden servir para su futura revisión.

Modelos UML:

Un modelo es una abstracción (una representación o vista) de "algo", que aplicado a nuestro campo puede ser un sistema informático, una aplicación, etc.

En un modelo podemos interpretar los siguientes elementos de construcción:

• Elementos: Los elementos son abstracciones de cosas reales o ficticias (objetos, acciones, etc.)
• Relaciones: relacionan los elementos entre sí.
• Diagramas: Son colecciones de elementos con sus relaciones.

La construcción de un modelo aporta las siguientes ventajas:

• Es posible enseñar al cliente una posible aproximación de lo que será el producto final.
• Proporcionan una primera aproximación al problema que permite visualizar cómo quedará el resultado.
• Divide un problema complejo en varios problemas de menor complejidad y por tanto más fáciles de resolver.

UML recomienda la utilización de nueve diagramas para representar las distintas vistas de un sistema.

Los diagramas de los que se compone UML:

• Diagramas de casos de Uso: captura los requisitos del sistema, es decir, qué funciones va a realizar el sistema, desde el punto de vista de la interacción con el usuario.
• Diagramas de clases: Es el diagrama principal de UML.
• Diagramas de Objetos: Muestran una serie de objetos (instancias de las clases) y sus relaciones. Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Su representación gráfica sería equivalente a la del diagrama de clases pero más detallado.
• Diagramas de estado: Se utilizan para analizar los cambios de estado de los objetos. Muestran los estados, eventos, transiciones y actividades de los diferentes objetos. Estos diagramas son útiles en sistemas orientados a eventos.
• Diagramas de Actividad: son un caso especial del diagrama de estados, simplifica el diagrama de estados modelando el comportamiento mediante flujos de actividades. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.
• Diagramas de Secuencia: capturan la interacción entre los objetos y los mensajes que intercambian entre sí atendiendo al orden temporal de los mismos.
• Diagramas de colaboración: igualmente, muestra la interacción entre los objetos resaltando la organización estructural de los objetos en lugar del orden de los mensajes intercambiados.
• Diagramas de componentes: muestra la organización y las dependencias entre un conjunto de componentes. Se usan para agrupar clases en componentes o módulos.
• Diagramas de Despliegue: muestra los dispositivos que se encuentran en un sistema y su distribución en el mismo. Se utiliza para identificar Sistemas de Cooperación: Durante el proceso de desarrollo el equipo averiguará de qué sistemas dependerá el nuevo sistema y qué otros sistemas dependerán de él.

Clasificación de los diagramas:

Y según la agrupación que realicemos de los diagramas podemos hablar de que se genera una vista u otra del sistema, es decir, obtenemos diferentes modelos del sistema. De esta forma mediante distintos modelos representamos el producto desde las diferentes perspectivas de interés.

Según la agrupación que hagamos de diagramas encontramos las siguientes vistas del sistema:


Los diagramas más importantes y los más usados son los de casos de uso, clases y secuencia.