8-3-2018 Diagramas UML

parte 2
Docente: Yolanda Catalina Navarrete
Beas
Alumno: Ricardo Martínez Campos
Grupo: 410

Conalep
 Página 1 de 26

DIAGRAMA DE CLASES
El propósito de este diagrama es el de representar los objetos fundamentales del
sistema, es decir los que percibe el usuario y con los que espera tratar para
completar su tarea en vez de objetos del sistema o de un modelo de
programación.

• La clase define el ámbito de definición de un conjunto de objetos.

• Cada objeto pertenece a una clase.
• Los objetos se crean por instanciación de las clases.
Cada clase se representa en un rectángulo con tres compartimientos:

La primera representa el título de la clase, en este caso la clase Motocicleta.

La segunda representa los atributos de clase, tenemos color cilindrada, velocidad

máxima.

La tercera representa los métodos de la clase, en este caso posee arrancar,

acelerar, frenar, apagar.

DIAGRAMA DE CLASES: ATRIBUTOS.

• Tipo: puede llegar a depender del lenguaje de programación a utilizar.
• Valor inicial: valor que poseerá el atributo al crear un objeto.
• Visibilidad: está relacionado con el encapsulamiento.
• Multiplicidad: determinar si un atributo debe estar o no, y si posee un único
valor o una lista de valores.
• Ordenamiento: especifica si el atributo determina alguna relación de orden
dentro de la clase.
• Capacidad de cambio: permite definir atributos con valores constantes.
• Modificadores: un atributo puede ser de clase, derivado, volátil, transitorio.
Visibilidad
El encapsulamiento presenta tres ventajas básicas:
• Se protegen los datos de accesos indebidos
• El acoplamiento entre las clases se disminuye
 Página 2 de 26

• Favorece la modularidad y el mantenimiento

Los atributos de una clase no deberían ser manipulables directamente por el
resto de objetos.

Niveles de encapsulamiento: (-) Privado: es el más fuerte. Esta parte es totalmente

invisible desde fuera de la clase (excepto para clases friends en terminología
C++).

(~) Package : Sólo es visible dentro del mismo package.

(#) Los atributos/operaciones protegidos están visibles para las clases
friends y para las clases derivadas de la original.
(+) Los atributos/operaciones públicos son visibles a otras clases (cuando se
trata de atributos se está transgrediendo el principio de encapsulamiento)

DIAGRAMA DE CLASES: MÉTODOS.

Un método u operación es un servicio que una instancia de la clase puede
realizar.

• Tipo devuelto: puede llegar a depender del lenguaje de programación a utilizar.

• Parámetros: además del tipo, puede especificarse si son In, Out o InOut.

• Visibilidad: está relacionado con el encapsulamiento.

• Modificadores: una operación puede ser de clase, abstracta, query o constructor.

DIAGRAMA DE CLASES: ASOCIACIÓN.

• La asociación expresa una conexión bidireccional entre objetos.

• Una asociación es una abstracción de la relación existente en los enlaces entre

los objetos.

• Identificado como un nombre a los finales de la asociación, describe la semántica

de la relación en el sentido indicado.

• Cada asociación tiene dos roles; cada rol es una dirección en la asociación.
 Página 3 de 26

DIAGRAMA DE CLASES: Agregación.

Es una asociación especial, una relación del tipo “todo/parte” dentro de la cual una
o más clases son partes de un conjunto.

DIAGRAMA DE CLASES: Asociación Calificada.

• Un calificador es un atributo (o tupla de atributos) de la asociación cuyos valores
sirven para particional el conjunto de objetos enlazados a otro.

• Un calificador se representa como un pequeño rectángulo conectado al final de

una asociación y a la clase.

• El rectángulo del calificador es parte de la asociación, y no parte de la clase.

DIAGRAMA DE CLASES: Generalización.

• Una generalización se refiere a una relación entre una clase general (superclase
o padre) y una versión más específica de dicha clase (subclase o hija).

DIAGRAMA DE CLASES: Calificación Dinámica.

• En ambos casos se recomienda considerar generalizaciones / especializaciones
disjuntas

• Usando discriminadores se pueden tener varias especializaciones de una misma

clase padre

Diagrama de Clases: Clase de asociación

Es una asociación y una clase simultáneamente.

• Hay que tener en cuenta dónde se colocan los atributos.

DIAGRAMA DE CLASES: DEPENDENCIA.

Posibles dependencias entre clases

• use: el funcionamiento del origen depende de la presencia del destino

• Instánciate: el origen crea instancias del destino

 Página 4 de 26

• derive: el origen puede calcularse a partir del destino

• refine: el origen está un grado de abstracción más detallado.

• bind(): derivación genérica de una plantilla

• friend: visibilidad característica de C++

DIAGRAMA DE CLASES: INTERFACES.

• Una interfaz es una colección de operaciones que representan servicios
ofrecidos por una clase o componente.

• Por definición, todas estas operaciones tendrán una visibilidad pública.

• La interfaz especifica algo similar a un contrato que la clase se compromete a

respetar.

• La clase realiza (o suministra una realización de) una o varias interfaces.

• UML define dos tipos de interfaces: interfaz suministrada e interfaz requerida.

DIAGRAMA DE CLASES: INTERFACES

• Las interfaces requeridas son aquellas que necesita una clase para realizar su
cometido. El símbolo utilizado para representarla es un semicírculo.

Por experiencia propia, recomendamos usar este Software de creación de

diagramas de clases.
Página 5 de 26
Página 6 de 26
Página 7 de 26
 Página 8 de 26

Simbología
Dentro de las herramientas usadas para solución de problemas de programación es el uso de
"Simbología", una de las herramientas más usadas son lo Diagramas que se explican su uso a
continuación:

Diagrama de Flujo: Un "Diagrama de Flujo" de define como un representación gráfica usada

para la definición, análisis o solución de un problema en la que los símbolos se utilizan para
representar operaciones, datos, flujos, etc.
También se puede definir que es la representación detallada en forma gráfica de los pasos a
seguir para la solución de un problema de computadora. Esta representación gráfica se da
cuando varios símbolos, se relacionan entre sí mediante líneas que indican el orden en que se
deben ejecutar los procesos. Los símbolos utilizados para el manejo de "Diagramas de Flujo"
han sido normalizados por el Instituto Norteamericano de Normalización (ANSI).

Otra defunción usada: Un "Diagrama de Flujo" se define como una representación gráfica de
un algoritmo, donde un Algoritmo es una secuencia de pasos finitos para la solución de
problemas.
El "Diagrama de Flujo" es una de las técnicas de representación de algoritmo más utilizada
para la solución de problemas de programación.

¿Qué son las clases Públicas, protegidas, Privadas

y Locales?
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:
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”.
 Página 9 de 26

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 súper-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.
 Página 10 de 26

¿QUÉ ES UN DIAGRAMA DE OBJETOS EN

UML?
Un diagrama de objetos UML representa una instancia específica de un diagrama de
clases en un determinado momento en el tiempo. Cuando se lo representa gráficamente,
verás muchas similitudes con el diagrama de clases. Usamos el mismo ejemplo de clase
de coche de la página de diagramas de clases para ilustrar los diagramas de objetos.
Nuestra biblioteca de figuras UML puede ayudarte a diseñar cualquier diagrama de
objetos personalizado por medio de nuestra herramienta UML en línea.
Diagrama de objetos vs. Diagrama de clases

Ejemplo de diagrama de objetos

Ejemplo de diagrama de clases

Un diagrama de objetos se enfoca en los atributos de un conjunto de objetos y cómo esos
objetos se relacionan entre sí. Por ejemplo, en el siguiente diagrama de objetos, las tres
cuentas bancarias están ligadas al banco mismo. Los títulos de clase muestran el tipo de
cuentas (ahorros, corriente y tarjeta de crédito) que un cliente dado podría tener con este
banco en particular. Los atributos de clase son diferentes para cada tipo de cuenta. Esto
se ilustra por el hecho de que el objeto de tarjeta de crédito tiene un límite de crédito,
mientras que las cuentas de ahorros y corriente tienen tasas de interés. El diagrama de
objetos no está limitado a casos de uso bancario. Puedes crear un diagrama de objetos
para árboles genealógicos, departamentos corporativos, es decir, cualquier sistema con
partes interrelacionadas.
 Página 11 de 26

Aplicaciones de los diagramas de objetos

Hay muchos casos en los que a un desarrollador le resultarían útiles los diagramas de
objetos. Dichos casos incluyen:

 Revisión de una iteración específica de un sistema general.

 Obtención de una vista de nivel alto del sistema que desarrollarás.
 Prueba de un diagrama de clases que creaste para la estructura general del sistema, por
medio de diagramas de objetos para casos de uso específicos.

Elementos de los diagramas de objetos

Los diagramas de objetos son sencillos de crear: se componen de objetos, representados

por rectángulos, conectados mediante líneas. Estos son los elementos principales de un
diagrama de objetos:

 Objetos - son instancias de una clase. Si un coche es una clase, un Altima 2007 de
Nissan es un objeto de una clase. Los objetos en la clase "Padres" son tus padres
específicos, por ejemplo, Elaine y Gary.
 Títulos de clases - los atributos específicos de la clase. En el diagrama de objetos de
árbol genealógico, se trata del nombre, género y edad de los integrantes de la familia. Se
pueden enumerar como elementos en el objeto o incluso en las propiedades del propio
objeto (p. ej., color).
 Página 12 de 26

 Atributos de clases - un rectángulo con dos pestañas que indica un elemento de

software.
 Enlaces - se trata de las líneas que conectan un objeto con otro. El diagrama de objetos
corporativo siguiente muestra cómo los departamentos están conectados en un estilo de
organigrama tradicional.

Otros ejemplos de diagramas de objetos UML

Las especificaciones UML realmente no cambian cuando describimos un diagrama de

objetos en diferentes lenguajes de programación. La idea de UML es que podamos
planificar software independientemente de las plataformas específicas. A continuación se
encuentran los tipos de diagramas de objetos más comúnmente buscados en diferentes
lenguajes de programación.

Diagrama de objetos en Objective C

Objective C se ha vuelto muy popular desde el lanzamiento de "Objective C 2.0" de Apple,

y ahora es el lenguaje de programación preferido para las aplicaciones de la tienda virtual
de Apple. Alguien que busque un diagrama de objetos en Objective C probablemente esté
intentando mostrar instancias de una aplicación de iPhone.
 Página 13 de 26

¿QUÉ ES UN DIAGRAMA DE
CASOS DE USO EN UML?
Para obtener la documentación más reciente de Visual Studio 2017,
consulte Documentación de Visual Studio 2017.
En Visual Studio, puede dibujar un diagrama de casos de uso donde se resuma quién usa
la aplicación o sistema, y qué pueden hacer. Para crear un diagrama de casos de uso
UML, vaya al menú Arquitectura y haga clic en Nuevo diagrama de capas o UML.
Si desea una demostración, vea el vídeo sobre la organización de características en
casos de uso.
Para ver las versiones de Visual Studio compatibles con esta característica,
vea Compatibilidad de versiones con las herramientas de arquitectura y modelado.
Con la ayuda de un diagrama de casos de uso, puede analizar y comunicar:
 Los escenarios en los que el sistema o aplicación interactúa con personas,
organizaciones o sistemas externos.
 Los objetivos que el sistema o aplicación contribuye a lograr.
 El ámbito del sistema.
En un diagrama de casos de uso no se muestran los casos de uso en detalle; solamente
se resumen algunas de las relaciones entre los casos de uso, los actores y los sistemas.
En concreto, en el diagrama no se muestra el orden en que se llevan a cabo los pasos
para lograr los objetivos de cada caso de uso. Esos detalles pueden describirse en otros
diagramas y documentos, que pueden vincularse a cada caso de uso. Para obtener más
información, vea en este tema la sección Describir los casos de uso en detalle.
En las descripciones que se proporcionen de los casos de uso se usarán diversos
términos relacionados con el dominio en el que trabaja el sistema, como Ventas, Menú,
Cliente, etc. Es importante definir de manera clara estos términos y sus relaciones y, para
ello, puede resultar útil un diagrama de clases de UML. Para obtener más información,
vea Diagramas de clases de UML: Instrucciones.
Los casos de uso solamente se usan para los requisitos funcionales de un sistema. Otros
requisitos, como las reglas de negocio, los requisitos de calidad del servicio y las
restricciones de implementación, deben representarse por separado. La arquitectura y los
detalles internos también deben describirse por separado. Para obtener más información
sobre cómo definir los requisitos de usuario, vea Requisitos del usuario de modelos.
Los ejemplos que se usan en este tema están relacionados con un sitio web en el que los
clientes pueden hacer pedidos de comida de restaurantes locales.
 Página 14 de 26

 Un actor (1) es una clase de persona, organización, dispositivo o componente de

software externo que interactúa con el sistema. Los actores del ejemplo son
cliente, restaurante, sensor de temperatura y titular de tarjeta de crédito.
 Un caso de uso (2) representa las acciones que uno o varios de los actores
realizan a fin de conseguir un objetivo determinado. Los casos de uso del ejemplo
son “Pedir menú”, “Actualizar menú” y “Procesar pago”.
En un diagrama de casos de uso, casos de uso están asociados (3) a los actores
que los realizan.
 El sistema (4) es aquello que se está desarrollando. Puede ser un pequeño
componente de software cuyos actores simplemente son otros componentes de
software; puede ser una aplicación completa; o puede ser un gran conjunto de
aplicaciones distribuidas que se implementan en muchos equipos y dispositivos.
Los subsistemas del ejemplo son “Sitio web de pedidos de menú”, “Empresa de
entrega de menús” y “Versión 2 del sitio web”.
En un diagrama de casos de uso pueden mostrarse los casos de uso que el
sistema o sus subsistemas admiten.
En este tema
Pasos básicos para dibujar diagramas de casos de uso
Dibujar actores y casos de uso
Describir los casos de uso en detalle
Estructurar casos de uso
Usar límites de subsistema
Pasos básicos para dibujar diagramas de casos de uso

Nota

En Editar modelos y diagramas UML se describen en detalle los pasos para crear
diagramas de modelado.
Para crear un nuevo diagrama de casos de uso
1. En el menú Arquitectura, haga clic en Nuevo diagrama UML o de capas.
 Página 15 de 26

2. En Plantillas, haga clic en UML Diagrama de casos de uso.

3. Especifique un nombre para el diagrama.
4. En Agregar a proyecto de modelado, seleccione un proyecto de modelado
existente en la solución o Crear nuevo proyecto de modelado y, a continuación,
haga clic en Aceptar.
Para dibujar un diagrama de casos de uso
1. Arrastre los límites de subsistema desde el cuadro de herramientas al diagrama
para representar el sistema completo o sus principales componentes.
o Si no desea describir los casos de uso que el sistema o sus componentes
admiten, puede dibujar un diagrama de casos de uso sin límites de
sistema.
o Si es necesario, arrastre la esquina de un sistema para hacerlo más
grande.
o Cambie su nombre como corresponda.
2. Arrastre los Actores desde el cuadro de herramientas al diagrama (sitúelos fuera
de los límites de sistema).
o Los actores representan las clases de usuarios, organizaciones y sistemas
externos que interactúan con el sistema.
o Cámbieles el nombre. Por ejemplo: cliente, restaurante, entidad de tarjeta
de crédito.
3. Arrastre los Casos de uso desde el cuadro de herramientas a los sistemas
adecuados.
o Los casos de uso representan las actividades que los actores realizan con
la ayuda del sistema.
o Asígneles títulos que los propios actores puedan reconocer. No use títulos
que tengan relación con el código. Por ejemplo: “Pedir menú”, “Pagar
menú” o “Entregar menú”.
o Comience con las transacciones principales, como “Pedir menú”, y
posponga para más adelante las transacciones más pequeñas, como
“Elegir elemento del menú”.
o Sitúe cada caso de uso en el sistema o el subsistema principal compatible
(omita los elementos de fachada o los componentes que solamente están
implicados en la conexión con el usuario).
o Puede dibujar un caso de uso fuera del límite de sistema para mostrar que
dicho caso de uso no es compatible con el sistema en una determinada
versión.
4. En el cuadro de herramientas, haga clic en Asociación, luego en un caso de uso y
después en un actor que participe en el caso de uso. Vincule los actores con sus
casos de uso de la misma manera.
5. Estructure los casos de uso con las
relaciones Incluir, Extender y Generalización. Para crear cada uno de estos
vínculos, haga clic en la herramienta, luego en el caso de uso de origen y por
último en el destino. Vea más adelante la sección titulada Estructurar casos de
uso.
6. Describa los casos de uso con más detalle. Vea más adelante la sección
titulada Describir los casos de uso en detalle.
 Página 16 de 26

7. Dibuje otros diagramas para hacer hincapié en diferentes subsistemas o grupos de

casos de uso relacionados. Todos los diagramas de un proyecto de modelado son
vistas del mismo modelo.
Dibujar actores y casos de uso
El propósito principal de un diagrama de casos de uso es mostrar quién interactúa con el
sistema y los principales objetivos que se logran con él.
 Cree Actores que representen clases de personas, organizaciones, otros
sistemas, software o dispositivos que interactúan con el sistema o subsistema.
o Para obtener información sobre cómo se dibujan actores y otros elementos,
vea Editar modelos y diagramas UML.
o En cada uno de los conjuntos de objetivos, identifique los actores en
función de su tipo o rol, aun cuando las entidades o personas físicas sean
las mismas. Por ejemplo, “Restaurante” y “Cliente” son actores diferentes,
aunque un empleado del restaurante podría ocasionalmente actuar como
cliente.
 Crear Casos de uso para cada uno de los objetivos que los actores pretendan
conseguir con el sistema.
o Asigne un nombre y una descripción para los casos de uso; use palabras
que el actor pueda entender y no emplee términos relacionados con la
implementación.
 Use Asociaciones para vincular actores con casos de uso.
Herencia entre actores

Puede dibujar un vínculo de Generalización entre actores. El actor especializado

(“Cliente de club” en el ejemplo) hereda los casos de uso del actor general (“Cliente” en el
ejemplo). La punta de flecha debe apuntar al actor más general, como “Cliente”. Cuando
cree el vínculo, apunte primero al actor más especializado.
El actor especializado puede tener otros casos de uso propios que no están disponibles
para el resto de actores.

Precaución

No genere bucles de relaciones de generalización en los que, como resultado, un actor

se generalice a sí mismo. Los bucles pueden producir errores.
 Página 17 de 26

Iconos de actores alternativos

Puede usar iconos personalizados para representar a un actor en lugar del dibujo
estándar. Por ejemplo, puede cambiar el icono para que tenga un aspecto similar a un
dispositivo, restaurante, banco, etc.
Para cambiar la apariencia de un actor
1. Haga clic con el botón derecho en el actor y, a continuación, haga clic
en Propiedades.
Aparece la ventana Propiedades.
2. Establezca la propiedad Ruta de la imagen en la ubicación de un archivo de
imagen.
o Puede usar cualquiera de los diversos formatos de imagen, como .bmp,
.jpg y .gif.
o Use un archivo que esté incluido en el control de código fuente de la
solución o proyecto para que siga disponible cuando la solución se mueva
o copie.
3. Para replicar esta apariencia en otros diagramas de casos de uso, copie al actor y
péguelo en otro diagrama.
o El cambio de imagen solo se aplica a la vista de un diagrama determinado,
pero no al elemento del modelo subyacente. Si arrastra el actor desde el
Explorador de modelos UML a otro diagrama, aparecerá como el dibujo
estándar.

Multiplicidades entre actores y casos de uso

La asociación entre un actor y un caso de uso puede mostrar una multiplicidad en cada
extremo.

Nota

Las multiplicidades de una asociación en un diagrama de casos de uso se ocultan si las

dos tienen un valor de 1.
De forma predeterminada, cada multiplicidad es 1. En una interpretación estricta del
modelo, una multiplicidad de 1 significa que, por ejemplo, solo un cliente está implicado en
el pedido de comida y que cada cliente pide exclusivamente un menú cada vez.
Estas multiplicidades se pueden cambiar.
Por ejemplo:
 Página 18 de 26

 Para indicar que varios actores de la misma clase pueden participar en una única
instancia de un caso de uso, establezca la multiplicidad del extremo del actor de la
asociación en 1..*.
En la ilustración, uno o varios restaurantes pueden participar en la elaboración del
mismo pedido de menú.
 Para mostrar que cada actor puede participar al mismo tiempo en varias instancias
de un caso de uso, establezca la multiplicidad del extremo del caso de uso de la
asociación en *.
En la ilustración, cada restaurante puede trabajar en la realización de más de un
pedido a la vez.
Para establecer las multiplicidades de una asociación
1. Haga clic con el botón derecho en la asociación y, a continuación, haga clic
en Propiedades.
2. Expanda el Primer rol o el Segundo rol.
Rol hace referencia al elemento de un extremo de la asociación.
3. Elija en la lista uno de los valores siguientes para la propiedad de multiplicidad:
o 1 para indicar que exactamente una instancia de este rol participa en cada
vínculo.
o 1..* para indicar que una o varias instancias de este rol participan en cada
vínculo.
o 0..1 para indicar que la participación es opcional.
o * para indicar que cero o más instancias de este rol participan en el vínculo.

Nota

Muchos equipos no incluyen información de multiplicidad en los diagramas de casos de

uso, dejando las multiplicidades con el valor predeterminado de 1. En su lugar,
proporcionan la información en descripciones independientes de los casos de uso. En
este caso, se ocultarán todas las multiplicidades de los diagramas de casos de uso.
Usar un actor o un caso de uso en varios diagramas
Puede mostrar los mismos actores y casos de uso en varios diagramas. Por ejemplo:
 Los distintos casos de uso en los que está involucrado un actor se pueden
describir en diagramas diferentes.
 Se puede usar un diagrama para mostrar los actores y subsistemas a los que un
caso de uso está asociado y usar otro diagrama para mostrar cómo se estructura
el caso de uso con la inclusión y ampliación de casos de uso.
 Página 19 de 26

Para mostrar el mismo actor o caso de uso en diagramas diferentes

1. Crear el actor o el caso de uso en un diagrama.
2. Cree otro diagrama de casos de uso.
3. Arrastre un actor o caso de uso desde el Explorador de modelos al nuevo
diagrama.

Nota

Si en el nuevo diagrama se coloca un actor y un caso de uso que ya están

asociados, la asociación entre ellos aparecerá automáticamente en el nuevo
diagrama.

Describir los casos de uso en detalle

Un caso de uso representa:
 el objetivo de un actor al usar el sistema, como “Comprar un menú”; y
 uno o más escenarios, es decir, secuencias de pasos que se realizan para
conseguir el objetivo, como: {Pedir menú, Pagar, Entregar}. Además de los
escenarios correctos, puede haber diferentes escenarios de excepciones o
errores, como “Tarjeta de crédito rechazada”.
Un caso de uso se puede describir con diferentes niveles de detalle. En una fase inicial
del diseño, basta con indicar el nombre en el diagrama de casos de uso. Posteriormente,
se pueden incluir descripciones más detalladas de los escenarios.
En Visual Studio Ultimate, un caso de uso puede describirse de varias maneras, que
pueden usarse por separado o de forma conjunta:
 Puede vincular el caso de uso a otro diagrama o diagramas del proyecto.
o Un diagrama de actividades ayuda a explicar un proceso más complejo que
presenta bucles, bifurcaciones y subprocesos paralelos. También puede
mostrar el flujo de datos entre elementos del proceso. Para obtener más
información, vea Diagramas de actividades UML: Instrucciones.
o Un diagrama de secuencia ayuda a explicar una serie compleja de
interacciones entre diferentes actores. También se puede usar para
mostrar la respuesta del sistema ante cada caso de uso. Para obtener más
información, vea Diagramas de secuencia de UML: Instrucciones.
 Vincule el caso de uso a una página, sección o párrafo de OneNote que describa
el caso de uso en detalle.
 Vincule el caso de uso a un documento de Word en el que use texto, capturas de
pantalla, etc. para describir los escenarios del caso de uso. Para obtener más
información, vea Requisitos del usuario de modelos.
Para vincular un caso de uso a un diagrama o a un archivo en la misma solución
1. Dibuje un diagrama, por ejemplo un diagrama de secuencia o de actividades, para
mostrar un escenario del caso de uso.
2. Vuelva al diagrama de casos de uso.
3. Arrastre el diagrama o el archivo desde el Explorador de soluciones a una zona
vacía del diagrama de casos de uso.
4. Asocie el artefacto con el caso de uso mediante una Dependencia.
 Página 20 de 26

Para vincular a un archivo de solución, por ejemplo a un documento de Word o a

una presentación de PowerPoint
1. Cree un documento que use texto, capturas de pantalla, etc. para describir el
escenario del caso de uso.
2. Agregue el documento a la solución.
a. Mueva el documento de Word a la misma carpeta de Windows que la
solución.
b. En el Explorador de soluciones, haga clic con el botón derecho en la
solución, elija Agregar y, después, haga clic en Elemento existente.
c. Navegue al documento de Word y haga clic en Agregar.
El documento de Word aparece en una carpeta de la solución en el
Explorador de soluciones.
3. Arrastre el documento de Word desde el Explorador de soluciones a una parte en
blanco del diagrama de casos de uso.
Aparece un nuevo artefacto.
4. Asocie el artefacto con el caso de uso mediante una Dependencia.
Para vincular un documento compartido, elemento de OneNote o página web
1. Obtenga la dirección URL del elemento compartido. Por ejemplo, esta puede ser
una ruta de acceso al archivo de red que comience por '\\', o una página web o
dirección URL de Sharepoint que comience por 'http://', o un vínculo a una sección,
página o párrafo de OneNote que comience por 'onenote:'.
2. En el cuadro de herramientas, haga clic en Artefacto y después en el diagrama de
casos de uso.
3. Con el nuevo artefacto seleccionado, escriba o pegue la dirección URL en la
propiedad Hipervínculo.

Nota

Haga doble clic en un artefacto para abrir el diagrama o documento al que está
vinculado.
Vincular casos de uso a elementos de trabajo
Si el proyecto usa Visual Studio Team Foundation Server 2010 y tiene Team Explorer,
puede vincular cada caso de uso a un elemento de trabajo de Team Foundation. Si quiere
saber cómo hacerlo, vea Vincular elementos de modelo con elementos de trabajo.
Esto le permite:
 Describir el caso de uso en el elemento de trabajo vinculado. En concreto, si en el
proyecto usa la plantilla de procesos formales de Visual Studio, puede establecer
vínculos con un elemento de trabajo de casos de uso. Este tipo de elemento de
trabajo proporciona campos para describir los objetivos y escenarios del caso de
uso.
 Vincular casos de prueba al caso de uso para obtener informes sobre hasta qué
punto el código que se está desarrollando implementa el caso de uso.
 Vincular tareas al caso de uso para que pueda hacer un seguimiento del progreso
de desarrollo.
Estructurar casos de uso
 Página 21 de 26

Es conveniente que intente describir el comportamiento del sistema con solo unos pocos
casos de uso principales. En cada caso de uso grande se define un objetivo principal que
un actor logra, como comprar un producto o, desde el punto de vista del proveedor,
ofrecer productos para su venta.
Una vez que haya presentado estos objetivos con claridad, puede proporcionar más
detalles sobre cómo se consigue cada objetivo y sobre las variaciones de los objetivos
básicos.
Evite detallar en demasía los casos de uso. Los casos de uso hacen referencia a la
experiencia de los usuarios en su sistema y no a sus mecanismos internos. Además,
normalmente le resultará más eficaz crear versiones de trabajo del código en lugar de
invertir tiempo en estructurar casos de uso con mucho detalle.
Puede usar un diagrama de casos de uso para resumir las relaciones entre los casos de
uso principales y los casos de uso más detallados. En las secciones siguientes se
describe cómo:
 Mostrar los detalles de un caso de uso con la relación de inclusión
 Compartir los objetivos con la relación de generalización
 Descomponer las variaciones de casos con la relación de extensión
Mostrar los detalles de un caso de uso con la relación de inclusión
Use la relación Incluir para mostrar que en un caso de uso se describen algunos detalles
de otro. En la ilustración, “Pedir un menú” incluye “Pagar”, “Elegir menú” y “Elegir
elemento del menú”. Cada uno de los casos de uso incluidos y más detallados constituye
un paso que probablemente el actor o actores tendrán que llevar a cabo para conseguir el
objetivo global del caso de uso incluyente. La flecha debe apuntar al caso de uso incluido
más detallado.

Precaución

No cree bucles de relaciones de inclusión en los que un caso de uso se incluya a sí

mismo. Los bucles pueden producir errores.
Los casos de uso incluidos se pueden compartir. En el ejemplo, los casos de uso “Pedir
un menú” y “Suscribirse a revistas” incluyen “Pagar”.
 Página 22 de 26

El objetivo y los escenarios de un caso de uso incluido deben tener sentido por sí mismos,
de modo que puedan incluirse en casos de uso que se diseñen posteriormente.
La descomposición de los casos de uso en elementos incluyentes y elementos incluidos
resulta útil para lograr los siguientes objetivos:
 Estructurar las descripciones del caso de uso en diferentes niveles de detalle.
 Evitar repetir escenarios compartidos en distintos casos de uso.
Definir el orden de los pasos detallados
En el diagrama de casos de uso no aparece ninguna información sobre el orden en que
deben realizarse los pasos más detallados, ni sobre si son siempre todos necesarios.
Si desea especificar con claridad el orden de los pasos, puede usar un artefacto para
asociar un documento independiente al caso de uso incluyente. En el ejemplo siguiente,
se muestra un diagrama de actividades asociado al caso de uso “Pedir un menú”. Si lo
desea, también puede usar un documento de texto que contenga una lista de pasos o una
secuencia de capturas de pantalla. Para obtener más información, vea Describir los casos
de uso en detalle.
Tenga en cuenta estas convenciones de nomenclatura cuando use un diagrama de
actividades:
 El nombre de la actividad global es el mismo que el caso de uso incluyente.
 Las acciones del diagrama de actividades tienen los mismos nombres que los
casos de uso incluidos.
Para obtener más información, vea Diagramas de actividades UML: Instrucciones.
 Página 23 de 26

Compartir los objetivos con la relación de generalización

Use una relación de generalización para mostrar que un caso de uso especializado es un
mecanismo específico de lograr los objetivos expresados por otro caso de uso general. La
punta de flecha abierta debe apuntar al caso de uso más general.

Por ejemplo, “Pagar” es una generalización de “Pagar con tarjeta de crédito” y “Pagar en
efectivo”.

Precaución
 Página 24 de 26

No genere bucles de relaciones de generalización en los que, como resultado, un actor

se generalice a sí mismo. Los bucles pueden producir errores.
Los casos de uso especializados pueden ayudarle a representar mecanismos distintos a
través de los cuales el sistema puede conseguir el mismo objetivo.
Se supone que los casos de uso especializados heredan los objetivos y los actores del
caso de uso general. El caso de uso general no tiene que tener escenarios propios; en
sus especializaciones se describen diferentes mecanismos para conseguir los objetivos.
Para refactorizar los objetivos comunes de dos o más casos de uso
1. Cree el nuevo caso de uso general y asígnele un nombre.
2. Cree una relación de Generalización con la gran flecha apuntando al nuevo caso
de uso general.
a. En el cuadro de herramientas, haga clic en Generalización.
b. Haga clic en un caso de uso especializado (“Pagar con tarjeta de crédito”
en el ejemplo).
c. Haga clic en el caso de uso general (“Pagar” en el ejemplo).
3. Si ha descrito los objetivos de los casos de uso especializados, transfiera las
partes comunes a la descripción del caso de uso general.
4. Los actores que se comparten entre los casos de uso especializados pueden
transferirse al caso de uso general.
Descomponer las variaciones de casos con la relación de extensión
Use un vínculo de extensión para mostrar que, en determinadas circunstancias, un caso
de uso puede agregar funcionalidad a otro caso de uso. La flecha debe apuntar al caso de
uso principal extendido.

Precaución

No genere bucles de relaciones de extensión en los que, como resultado, un actor se

generalice a sí mismo. Los bucles pueden producir errores.
Por ejemplo, el caso de uso “Iniciar sesión” de un sitio web normal puede incluir “Registrar
nuevo usuario”, pero solamente cuando el usuario todavía no tiene una cuenta.
Para descomponer un caso de uso en elementos principales y elementos de
extensión
1. Cree el nuevo caso de uso de extensión y asígnele un nombre.
2. Crear una relación de tipo Extender con la flecha apuntando al caso de uso
extendido.
a. En el cuadro de herramientas, haga clic en Extender.
b. Haga clic en el caso de uso extensor (“Registrar nuevo usuario” en el
ejemplo).
c. Haga clic en el caso de uso extendido (“Iniciar sesión” en el ejemplo).
 Página 25 de 26

Nota

Evite crear un bucle de relaciones de extensión en el diagrama. No es

correcto que un caso de uso sea una extensión de sí mismo.
3. Si ya ha creado los escenarios del caso de uso extendido, transfiera los pasos
pertinentes al escenario de la extensión.
4. La descripción de la extensión (“Registrar nuevo usuario” en el ejemplo) debe
incluir los detalles sobre el lugar de los escenarios de caso de uso principales en
que va a producirse y en qué circunstancias. Debe concebirse como una
modificación de la descripción del caso principal.
El caso de uso de extensión representa los pasos del escenario que, de otro modo,
formarían parte de los escenarios del caso de uso principal. El escenario y el objetivo de
la extensión siempre se interpretarán en el contexto del caso de uso principal y, por tanto,
no es necesario que resulten útiles por separado.
Descomponer las extensiones puede resultar útil para describir estas situaciones:
 Hay actores adicionales que solamente están implicados en el caso de uso de
extensión. Por ejemplo, es necesario que un administrador apruebe el registro de
un cliente en el sitio web.
 Un subsistema independiente se ocupará del caso de uso de extensión.
 Esta extensión tan solo estará disponible en versiones específicas del sistema.
Puede mostrar cada versión como un subsistema independiente en el diagrama de
casos de uso.
Usar límites de subsistema
Use un límite de subsistema para mostrar qué casos de uso están dentro del ámbito del
sistema.
Para dibujar un límite de subsistema
1. En el cuadro de herramientas, haga clic en Subsistema y después en el
diagrama.
Un subsistema aparece en el diagrama.
2. Arrastre las esquinas del subsistema para ajustar su tamaño.
3. Arrastre los casos de uso existentes dentro o fuera del subsistema hasta ajustar su
contenido.
o bien
Para crear directamente un nuevo caso de uso en un subsistema, haga clic en Caso de
uso en el cuadro de herramientas y luego haga clic en el interior del subsistema.

Nota

La propiedad Asuntos de un caso de uso indica qué subsistema es el que está

incluido.
 Página 26 de 26

Casos de uso fuera del ámbito del sistema

Normalmente, resulta útil incluir en el diagrama casos de uso que forman parte del
negocio pero que no tienen relación con el sistema que se está desarrollando. Esto ayuda
a los desarrolladores a entender el contexto de su trabajo. Por ejemplo, “Entregar menú”
podría presentarse como un caso de uso en el que están implicados los actores
“Restaurante” y “Cliente”, pero podría quedar fuera de la responsabilidad del sitio web de
pedidos de menús.
Varios subsistemas
Puede crear diversos límites de subsistema para representar el modo en que los distintos
componentes del sistema se ocupan de los diferentes casos de uso. Por ejemplo,
“Agregar valoración del restaurante” puede realizarse en un sitio web de foros
independiente. Recuerde que un diagrama de casos de uso debe ocuparse de aquello
que es visible para el usuario. Si desea describir la división interna del trabajo en el
sistema, considere la posibilidad de usar un diagrama de componentes.
Versiones del sistema
Puede usar diferentes límites de subsistema para mostrar distintas versiones del sistema.
Por ejemplo, el caso de uso “Pagar” podría estar incluido en la versión 2 del sitio web,
pero no en la versión 1. Esto significa que el sistema ayuda a los clientes a realizar sus
pedidos. Sin embargo, los clientes tienen que pagar al restaurante directamente.
Use las relaciones de Dependencia para vincular subsistemas que representan variantes
o versiones diferentes.