Diagramas en

UML

Programación Orientada a Objetos

Yolanda catalina Navarrete Beas

Sabrina Lizeth Torres Delgado 410

[TÍTULO DEL DOCUMENTO]

[Subtítulo del documento]
 Diagramas UML POO
¿Qué es un diagrama de clases?

Un diagrama de clases es una representación gráfica que sirve para representar la estructura de un sistema que será
implementado utilizando un lenguaje orientado a objetos. Los diagramas de clases se realizan en la fase de diseño del
software después de la fase de requisitos (más información sobre las fases de la ingeniería del software aquí). La idea de
estos diagramas es representar las clases que tendrá el sistema así como su contenido y sus relaciones con otras clases.
La implementación de sistemas medianamente grandes no sería abordable sin este tipo de diagramas, y aunque fuera
abordable se tardaría mucho más y sería más fácil cometer errores.

Componentes de un diagrama de clases

Los componentes que describiré son los que se incluyen en UML (Unified Modeling Language) que es el lenguaje de
modelado más extendido y más usado en todo el mundo.

Clase

Este es el elemento básico del diagrama de clases. Las clases representan entidades o conceptos. Normalmente cada vez
que aparece un sustantivo en un documento de descripción de un sistema ese sustantivo es una clase. En cada clase se
definen los atributos y métodos que tendrán los objetos de esa clase. La siguiente imagen es un ejemplo de
representación de una clase.

Atributos y métodos

Los atributos y los métodos se muestran con su nombre además de su tipo. En el caso de los métodos también se
muestra el tipo de retorno en caso de que retorne algo y el nombre y tipo de sus parámetros. Los atributos pueden
tener un valor inicial. Además, los símbolos que se encuentran antes del nombre de los atributos y métodos representan
la visibilidad de éstos:

El símbolo – representa atributos privados.

El símbolo + representa atributos públicos.

El símbolo # representa atributos protegidos.

Relaciones

Como he dicho antes las clases se relacionan con otras. En cada relación aparece el nombre del atributo que se usará
para representar esa relación y la multiplicidad. Las relaciones que existen son las siguientes:

Generalización: Esta relación representa la herencia o la extensión de una clase de otra. En la siguiente imagen podemos
ver un ejemplo.
 Diagramas UML POO

Asociación: Representa una relación básica entre dos clases. Pueden ser unidireccionales (sólo una de las clases conoce
a la otra) o bidireccionales (ambas clases tienen conocimiento de la otra). En la siguiente imagen podemos ver un
ejemplo. La primera es una asociación bidireccional que representa que un curso tiene desde 1 hasta varios alumnos y
que un alumno puede estar en 0 o varios cursos. La segunda es una asociación unidireccional que representa que una
asignatura tiene un único profesor responsable.

Agregación: Es un tipo de asociación con la que se representa que cada objeto de una de las clases contiene objetos de
la otra clase. El objeto contenedor seguirá existiendo aunque los objetos contenidos dejen de existir.

Composición: Es un tipo de asociación, pero podemos decir que son agregaciones fuertes. La diferencia con las
agregaciones es que no tiene sentido que el objeto contenedor siga existiendo si no existen los objetos contenidos.

Esta imagen representa la diferencia entre una agregación y una composición. Un vehiculo seguirá existiendo aunque no
existan sus ruedas (otra cosa es que pueda rodar). Sin embargo un libro no existirá si no existen sus capítulos. Pues esto
ha sido todo, espero que os sea útil y tanto si sabíais que era un diagrama de clases como si no, espero que os sirva para
saber lo que es, para lo que sirve y sepáis realizarlo sin errores.

Simbología del diagrama de clases

 Diagramas UML POO

Clases privadas, públicas y protegidas

Toda variable/función tiene un rango de acción, se encuentra en un sitio, tiene un contexto, fuera del cual pierde
significado y valor. Un ejemplo que puede ilustrar esto puede ser un lámpara. La lámpara, al encenderla, ilumina un área
específica, pero no tiene influencia fuera de esa área. Por ejemplo: si necesito buscar algo en mi cuarto, que la luz de la
sala o de la cocina estén encendidas sería irrelevante para mí porque mi cuarto está fuera del área que ellas iluminan,
pero si enciendo la luz de mi cuarto puedo buscar lo que necesito más claramente, aunque no tendría ninguna influencia
fuera de él, él ámbito (alcance) de esa luz se limita a mi cuarto.

De acuerdo con su ámbito una variable/función puede ser:

Pública

Privada

Protegida

Local

Vamos a hablar de estos ámbitos desde el punto de vista de la clase.

Public:

Una variable/función pública puede ser accedida desde fuera de la clase. Es decir, puedo acceder desde la instancia de la
clase y no sólo desde el código interno de la clase. Ejemplo de funciones públicas son los métodos de una clase. También
es posible crear variables públicas, para que puedan ser manejadas desde la instancia, pero no es algo común o
recomendable, entre otras cosas porque deja un hueco de seguridad en la clase, acabando con la idea de la
“encapsulación”. Para declarar una variable/función como pública, se le antepone la palabra clave “public”.

Private:
 Diagramas UML POO
Al contrario que las públicas, las variables/funciones privadas sólo pueden ser accedidas desde dentro de la misma clase.
Todo intento de llamarlas desde la una instancia de la misma es en vano. Mantener variables/funciones privadas
permiten tener un mayor control sobre la clase, sobre el modo como procesa sus métodos, como maneja sus variables,
etc. Para declarar una variable/función como privada, se le antepone la palabra clave “private”.

Protected:

Existe un tipo intermedio de ámbito, llamado “protegido”. Es un punto medio entre público y privado, porque -como
ocurre con las privadas- no se puede acceder a ella desde una instancia de la clase, pero -como ocurre con las públicas-
puede ser accedido desde las subclases de ésta, no importa si se encuentran o no en el mismo paquete. Básicamente
significa que, si una clase hereda de otra, tendrá acceso a las variables/funciones protegidas de la super-clase, de lo
contrario, no podrá acceder a ellas. Para declarar una variable como protegida, se le antepone la palabra clave
“protected”.

Local:

Una variable “local” sólo es accesible desde dentro de la función donde se declara; esto es válido tanto para los
parámetros de la función como para las variables declaradas dentro de ella. Una vez terminada la función, la variable es
destruida hasta que la función vuelve a ser invocada. No hay palabras clave para las variables locales.

Diagramas de Objetos

Los diagramas de objetos modelan las instancias de elementos contenidos en los diagramas de clases. Un diagrama de
objetos muestra un conjunto de objetos y sus relaciones en un momento concreto. En UML, los diagramas de clase se
utilizan para visualizar los aspectos estáticos del sistema y los diagramas de interacción se utilizan para ver los aspectos
dinámicos del sistema, y constan de instancias de los elementos del diagrama de clases y mensajes enviados entre ellos.
En un punto intermedio podemos situar los diagramas de objetos, que contiene un conjunto de instancias de los
elementos encontrados en el diagrama de clases, representando sólo la parte estática de una interacción, consistiendo
en los objetos que colaboraran pero sin ninguno de los mensajes intercambiados entre ellos. Los diagramas de objetos
se emplean para modelar la vista de diseño estática o la vista de procesos estática de un sistema al igual que se hace con
los diagramas de clases, pero desde la perspectiva de instancias reales o prototípicas. Esta vista sustenta principalmente
los requisitos funcionales de un sistema. Los diagramas de objetos permiten modelar estructuras de datos estáticas, En
general los diagramas de objetos se utilizan para modelar estructuras de objetos, lo que implica tomar una instantánea
de los objetos de un sistema en un cierto momento. Un diagrama de objetos representa una escena estática dentro de
la historia representada por un diagrama de interacción. Los diagramas de objetos se utilizan para visualizar, especificar,
construir y documentar la existencia de ciertas instancias en el sistema, junto a las relaciones entre ellas.
 Diagramas UML POO

Diagrama de caso de uso

Elementos de un caso de uso:

Conjunto de secuencias de acciones, cada secuencia representa un posible comportamiento del sistema.

Actores, se tratan de los roles que pueden jugar los agentes que interactúan con el sistema. Los roles son jugados por
personas, dispositivos, u otros sistemas. Podríamos distinguir entre actores primarios, para los cuales el objetivo del
caso de uso es esencial y actores secundarios, que interactúan con el caso de uso, pero cuyo objetivo no es esencial.

Variantes, son versiones especializadas, un caso de uso que extiende a otro o un caso de uso que incluye a otro

Como veremos a continuación, en los diagramas de casos de uso se muestran: casos de uso (representados en forma de
elipses), actores (en forma de personajes) y relaciones (en forma de líneas y/o flechas). UML define cuatro tipos de
relaciones en los diagramas de casos de uso:

Comunicación: Relación (asociación) entre un actor y un caso de uso. El estereotipo de la relación de comunicación es:
<<communicate>> aunque generalmente no se estipula ningún nombre, como podemos apreciar en el siguiente
ejemplo de comunicación:

Inclusión: Un caso de uso base incorpora explícitamente el comportamiento de otro en algún lugar de su secuencia. La
relación de inclusión sirve para enriquecer un caso de uso con otro y compartir una funcionalidad común entre varios
casos de uso, también puede utilizarse para estructurar un caso de uso describiendo sus subfunciones. El caso de uso
incluido existe únicamente con ese propósito, ya que no responde a un objetivo de un actor.
 Diagramas UML POO
Estas relaciones se representan mediante una flecha discontinua con el estereotipo <<include>>. Algunos casos de uso
típicos de inclusión son: comprobar, verificar, buscar, validar, autentificar o login… En principio, no deberíamos abusar
de este tipo de relación, para no hacer una descomposición funcional del sistema. A partir de UML 1.3 la relación
<<include>> reemplazó al denominado <<uses>>.

Veamos un ejemplo de inclusión entre casos de uso:

Extensión: Un caso de uso base incorpora implícitamente el comportamiento de otro caso de uso en el lugar
especificado indirectamente por este otro caso de uso. En el caso de uso base, la extensión se hace en una serie de
puntos concretos y previstos en el momento del diseño, llamados puntos de extensión, los cuáles no son parte del flujo
principal. La relación de extensión sirve para modelar: la parte opcional del sistema, un subflujo que sólo se ejecuta bajo
ciertas condiciones o varios flujos que se pueden insertar en un punto determinado. Este tipo de relación produce
confusión y no debería utilizarse en exceso. Conviene su uso sólo para insertar un nuevo comportamiento no previsto en
un caso de uso existente. Estas relaciones se representan mediante una flecha discontinua con el estereotipo
<<extend>>.

Veamos un ejemplo de extensión:

En este ejemplo usamos la relación de extensión entre los casos de uso Abrir acción de mejora y Resolver consulta. En
este caso tendremos el punto de extensión “resolución retrasada” (en el caso de uso Resolver consulta) debido a que
cuando haya pasado un tiempo estipulado por la organización (por ejemplo 3 días laborales) se abrirá una acción de
mejora para dejar constancia del retraso y realizar posteriormente las acciones pertinentes, de ahí que digamos que el
caso de uso Abrir acción de mejora es una subfunción de uso que puede extender al caso de uso Resolver consulta.

Especialización y generalización de los casos de uso: Un caso de uso (subcaso) hereda el comportamiento y significado
de otro, es decir las relaciones de comunicación, inclusión y extensión del super-caso de uso. En muchas ocasiones este
super-caso de uso es abstracto y corresponde a un comportamiento parcial completado en el subcaso de uso. O dicho
de otra manera, Los casos de uso “hijo” son una especialización del caso de uso “padre”. En la medida de lo posible
debería evitarse puesto que produce cierta confusión en algunas ocasiones.

Veamos un ejemplo de generalización:

 Diagramas UML POO
Como podemos ver en este último ejemplo también pueden existir vínculos de generalización o herencia entre actores.
Los actores especializados (Abogado y Psicólogo) heredan los casos de uso del actor general (Profesional). La punta de
flecha apunta al actor más general. Hay que reseñar que los actores especializados pueden tener otros casos de uso
propios que no estarán disponibles para los demás actores. Este tipo de herencia entre actores si que se usa
frecuentemente puesto que nos simplifica considerablemente el diagrama, nos ahorra un número importante de
relaciones de comunicación entre actores y casos de uso y nos sirve para esclarecer visualmente la jerarquía entre
actores del sistema.

Diagrama de objetos

Diagrama de Objetos Volver Los Diagramas de Objetos están vinculados con los Diagramas de Clases. Un objeto es una
instancia de una clase, por lo que un diagrama de objetos puede ser visto como una instancia de un diagrama de clases.

Los diagramas de objetos describen la estructura estática de un sistema en un momento particular y son usados para
probar la precisión de los diagramas de clases. Nombre de los objetos Cada objeto es representado como un rectángulo,
que contiene el nombre del objeto y su clase subrayadas y separadas por dos puntos.

Atributos Como con las clases, los atributos se listan en un área inferior. Sin embargo, los atributos de los objetos deben
tener un valor asignado.