02uml 1

UML
Diagramas de Clases y Casos de Uso
Ingeniería del Software 2

Curso 2008-2009
Prof.:Juan Carlos Gutiérrez Lázaro
Dep. Ingeniería del Software e Inteligencia Artificial

Facultad de Informática
Universidad Complutense Madrid
¿Qué es UML? – I
Unified Modelling Language

Lenguaje gráfico para modelado de sistemas
• especificar, visualizar, construir, documentar
Estándar abierto (OMG: Object Management Group)
Soporta todo el ciclo de vida de desarrollo de software
• Especificaciones de análisis, arquitectura, diseño,
implementación e implantación
Soporta distintas áreas de aplicación
• Sistemas distribuidos, tiempo real, aplicaciones monoproceso
• Sistemas de información corporativos (MIS), Banca/Finanzas,
Telecomunicaciones, Defensa/Espacio, Transporte, Distribución,
Electromedicina, Ciencia, etc.
Soportado por herramientas
• Rational Rose, Together, Objecteering, Paradigm Plus, Eclipse, ...
• Bouml
Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

ISIA, Facultad Informática UCM, curso 2008-2009 UML 2
ISIA, Facultad de Informática UCM, 2006-07
¿Qué es UML? – II
Unified Modelling Language

Proporciona un lenguaje común para simplificar el conjunto
de elementos del sistema y comunicarlos entre los diversos
implicados (stateholders)
Es un lenguaje de modelado gráfico utilizado para especificar
• Construye modelos precisos no ambiguos y completos.
NO es un método
• Cubre la especificación de todas las decisiones de análisis, diseño
e implementación en un sistema con gran cantidad de software.

¿Qué es UML? – III
UML (http://www.uml.org)
No es el objetivo (... Aplicación robusta flexible y escalable

...), es un medio
• Comunicarse entre desarrolladores
• Comunicarse con los clientes
• Usar herramientas de generación automática de código
No incluye:
• Normas de calidad (análisis y diseño orientado a objetos)
• Plantillas de artefactos (documentos de requisitos, de análisis, ..)
• Gestión de proyecto y configuración (estimación de costes, ...)
• Métricas (de calidad del sw, de resistencia al cambio, ...)

¿Qué es UML? – IV
Modelo de la arquitectura de un sistema
4+1 Vistas => Diagramas <= UML
Vista Diseño Vista Implementación

(funcionalidad) (ensamblado, configuración)
Vista Casos
de Uso
(Requisitos,
comportamiento)
Vista Proceso Vista Despliegue
(Rendimiento, escalabilidad, (topología del sistema, distribución,
procesamiento) entrega, instalación)
Cada vista es una proyección de la organización y

la estructura del sistema, centrada en un aspecto
particular del mismo.
Cada una de estas vistas puede existir por sí
misma, lo que permite que un determinado
usuario se centre en el aspecto que más le
interese.
Héctor
ISIA, Gómez
Facultad Gauchía (adapt.de
Informática Juan Pavón)
UCM, curso 2008-2009 UML UML
ISIA, Facultad de Informática UCM, 2006-07 5
¿Qué es UML? – V
Vista de Casos de Uso: incluye los casos de uso que describen

el comportamiento del sistema visto por sus usuarios finales,
analistas, equipos de pruebas.
Vista de Diseño: incluye las clases, interfaces y colaboraciones

que forman el vocabulario del problema y su solución (requisitos
funcionales).
Vista de Implementación: incluye los componentes que se

utilizan para ensamblar y hacer disponible el sistema físico.
Vista de Despliegue: incluye los nodos que forman la topología

hardware (distribución, entrega e instalación del sistema).
Vista de Procesos: incluye los hilos y procesos que forman los

mecanismos de concurrencia y sincronización de un sistema, así
como funcionamiento, capacidad de adaptación y rendimiento
del sistema.

Objetivos de UML
Definir un lenguaje de modelado visual fácil de aprender

pero rico en significado
Estándar, estable y configurable
Unificar las metodologías de análisis y diseño OO más
conocidas (Booch, OMT -Object Modelling Technique-,
Objectory)
e incluir ideas de otros lenguajes de modelado
Ser independiente de lenguajes de programación o
procesos particulares
Promover en el mercado el crecimiento de herramientas
CASE OO con soporte a UML
Soportar conceptos de desarrollo de alto nivel tales como
colaboraciones, frameworks, patrones y componentes
Tratar aspectos del desarrollo de software actual
escalabilidad, concurrencia, distribución, ejecutabilidad, etc.

Historia de UML

Ámbito de UML
Metodología de desarrollo de software OO
Técnicas
Proceso de Notación
Modelado
Recursos
Herramientas
...
Experiencia

Modelar
No se construye un edificio sin tener antes unos planos
Permite estructurar la solución a un problema

abstrayendo para gestionar la complejidad
experimentando varias soluciones
reduciendo los costes
gestionando el riesgo de errores
Ventajas de modelar
Permite ver el sistema desde varias perspectivas haciendo
más sencillo su entendimiento y desarrollo
Mejora la comunicación
• con el cliente
• del equipo de desarrollo
Notación gráfica: Gráficos revelan la información

Elementos de UML
Entidades
Estructurales
Comportamiento
Agrupamiento
Anotación
Relaciones
Diagramas

Entidades estructurales - I
Son los nombres de los modelos UML y representan

fundamentalmente las partes estáticas del modelo
(conceptos o entidades materiales)
Casos de uso
Clases
Interfaces
Colaboraciones
Componentes
Nodos

Entidades estructurales – II
Caso de uso: descripción de un conjunto de secuencias de

acciones que ejecuta un sistema y que produce un resultado
observable para un actor particular
Clase: descripción (abstracción lógica) de un conjunto de

objetos que comparten los mismos atributos, operaciones,
relaciones y semántica
Interfaz: colección de operaciones que especifican un servicio

de una clase o componente
Colaboración: define una interacción y es una sociedad de

roles y otros elementos que colaboran para proporcionar un
comportamiento cooperativo mayor que la suma de los
comportamientos de sus elementos.

Entidades estructurales – III
Componente: parte modular del diseño del sistema que

oculta su implementación tras un conjunto de interfaces
externas.
Representan elementos físicos
Sólo tienen operaciones y además únicamente alcanzables a través
de la interfaz del propio componente
Nodo: es un elemento físico que existe en tiempo de

ejecución y representa un recurso computacional, que
generalmente tiene alguna memoria y, a menudo, capacidad
de procesamiento (p.e. un servidor de archivos). Sirven para
modelar la topología del hardware sobre el que se ejecuta el
sistema.

Entidades de agrupamiento
Las entidades de agrupación son las partes organizativas
de los modelos UML
Paquete: es un mecanismo de propósito general para

organizar el propio diseño, dividiendo el sistema en
subsistemas
Es puramente conceptual (sólo existe en tiempo de
desarrollo).
Se visualiza gráficamente como una carpeta que incluye su
nombre y, a veces, su contenido.
Existen variaciones de paquetes como son:
• Framework
• Modelo
• Subsistema Reglas de
Forma de agrupamiento negocio
• Elementos que tienen el mismo servicio
• Alto grado de cohesión y poca colaboración con elementos de
paquetes diferentes

Entidades de comportamiento - I
Representan las partes dinámicas de los modelos UML,

es decir, el comportamiento en el tiempo y en el espacio.
Mientras que las ideas estáticas ayudan a que un analista

se comunique con el cliente, las ideas dinámicas ayudan al
analista a comunicarse con un grupo de desarrolladores.
Existen tres tipos de elementos de comportamiento:

Interacción
Máquina de estados
Actividad

Entidades de comportamiento – II
Interacción: conjunto de mensajes intercambiados entre

un conjunto de objetos, dentro de un contexto particular,
para alcanzar un propósito específico.
Card Bank
Trans- Cash System
action Withdrawal Cash interface

Entidades de comportamiento – III
Máquina de estados: comportamiento que especifica la

secuencia de estados por las que pasa un objeto o una
interacción durante su vida en respuesta a eventos, junto
con sus reacciones a estos eventos
Created
PIN code
Open
do: verify PIN-code Correct Cash Withdrawal
PIN-code
Wrong exit: cash delivered
PIN-code
Ready
Closed
exit: eject Card
Actividad: comportamiento que especifica la secuencia

de pasos que ejecuta un proceso computacional.

Entidades de comportamiento – IV
Elemento Énfasis
Interacción conjunto de objetos que interactúan

Se centra en el intercambio de
mensajes entre objetos y el orden de
los mensajes.
Máquina de estados ciclo de vida de un objeto

Se centra en los estados en los que se
puede encontrar y cómo transita de uno
a otro.
Actividad flujo entre los pasos ya sea de datos

o de control.

Entidades de anotación
Son los elementos explicativos del modelo UML

Comentarios para describir y hacer observaciones
Se utilizan a modos de notas sobre el modelo gráfico.
{constraint}
Emitir por fax

Relaciones
Dependencia
Asociación
Generalización

Vistas y Diagramas
Vistas
Parte Estática: aspecto de un sistema que destaca su
estructura
Parte Dinámica: aspecto de un sistema que destaca su
comportamiento
Diagramas
Diagrama estructural: muestra los aspectos estáticos de
un sistema que representan su estructura (esqueleto y
componentes)
Diagrama de comportamiento: muestra los aspectos
dinámicos de un sistema como aquellos que representan sus
partes mutables (varían con el tiempo).

Diagramas - I
Modelado Casos de Uso Modelado Estructural
Diagramas de Casos de Uso Diagramas de Clases
Modelado de Comportamiento Modelado de Implementación
Diagramas de Secuencia Diagramas de Componentes

Diagramas de Colaboración Diagramas de Desarrollo
Diagramas de Actividad
Diagramas de Estados

Diagramas – II
VARIAS PERSPECTIVAS DEL SISTEMA
Casos de uso
Clase Modelo de casos de uso
Objetos Modelo
Secuencia estructural
Colaboración
Estados Modelo de
Actividades
comportamiento
Componentes (sw) Modelo de
Despliegue (hw) implementación
(implantación)
Un modelo es un punto de vista particular del sistema

Modelo estructural – I
Visión del sistema que describe la estructura de los

objetos, incluyendo su clasificación, relaciones, atributos y
operaciones
Desarrollado por analistas, diseñadores y programadores
Muestra la estructura estática del sistema
Las entidades que existen (clases, interfaces, componentes,
nodos, etc.)
• Captura el vocabulario del sistema
La estructura interna
La relación con otras entidades
Se define mediante:
Diagramas estructurales estáticos
• Diagrama de clases
• Diagrama de objetos
Diagramas de implementación
• Diagrama de componentes
• Diagrama de implantación

Modelo estructural – II
Elementos de un diagrama estructural

Clase
• Descripción de un conjunto de objetos que
comparten los mismos atributos, operaciones,
relaciones y semántica
Interfaz
• Un conjunto nombrado de operaciones que «interface»
caracterizan el comportamiento de un elemento

Componente
• Una parte modular, reemplazable y significativa del
sistema que empaqueta implementación y expone
interfaces
Nodo
• Objeto físico de ejecución que representa un
recurso computacional (en ejecución con mem.)
Restricción
• Condición semántica para cambiar reglas {constraint}

Modelo estructural – III
Relaciones en un diagrama estructural

Asociación
• Relación entre dos o más clases que implica conexiones
entre sus instancias. Puede ser bidireccional o
unidireccional, dependiendo de si ambas conocen la
existencia la una de la otra o no
Agregación
• Forma especial de asociación que especifica una
relación todo-parte entre el agregado y la parte
componente. Si el ciclo de vida del objeto hijo está
ligado al superior la relación se se denomina
Composición
Generalización
• Relación taxonómica entre un elemento más general y
otro más concreto
Dependencia
• Relación entre dos elementos en la que un cambio en
uno de ellos afecta al otro (elemento dependiente)
Realización
• Relación entre una implementación y su especificación

Modelo estructural – IV
Visibilidad
UML identifica 4 tipos de visibilidad:
• + Public
• - Private
• # Protected
• ~ Package

Modelo estructural – V: D. estructurales estáticos
Muestra un grafo de elementos clasificados conectados

por relaciones estáticas
Dos tipos
Diagrama de clases: visión de clasificación
Diagrama de objetos: visión de instanciación

Clases – I : introducción
Representación
Nombre, atributos, métodos
Compartimentos con nombres
• Definidos por el usuario (además de los obligatorios)
• Ej: responsabilidades, excepciones
Para encontrar clases

Ver el D. de casos de uso y cada caso de uso
Buscar conceptos del dominio, objetos
Distintos niveles de detalle según se avanza
Los estereotipos pueden ayudar
Nombres que dicen algo sobre la clase en sí:
• <<meta-clase>>, <<type>>, <<implementationClass>>
nombres que agrupan atributos o operaciones:
• <<constructor>>, <<consulta>>
La información irrelevante en una etapa, no se pone: “. . .”

Clases – II : Atributos
Formato gráfico
Nombre de la clase
Clase Las clases son el
vocabulario y
Atributos (puede terminología del
omitirse)
área de
conocimiento
Métodos (puede
omitirse)
Tipos
Tipos UML: Integer, Boolean, String
Tipos de cualquier lenguaje de programación
Se pueden omitir en bocetos
Ejemplo
Nombre: String
Edad: Integer
Telefonos: String [1 .. *]

Clases – II : Atributos
Visibilidad
Símbolo Visibilidad
+ Público
- Privado
# Protegido
~ Paquete
Estáticos vs Instancia
Los miembros estáticos se subrayan
Los miembros de instancia NO se subrayan
Ejemplo
Nombre: String
Edad: Integer
Telefonos: String [1 .. *]

Clases – III : Relaciones
Relaciones entre clases

Son la proyección de la colaboración entre sus objetos (una persona
trabaja para una empresa, una empresa tiene una cantidad
determinada de sucursales, ...)
Características de la relaciones entre clases
Visibilidad
• Carácter privado o público de la colaboración entre dos objetos
Temporalidad
• Mayor o menor duración de la colaboración entre dos objetos
Versatilidad
• Intercambiabilidad de los objetos en la colaboración con otro objeto
Visibilidad
pública privada
duradera ASOC AGREG

Temporalidad
momentánea DEPENDENCIA
poca muy poca
Versatilidad
Clases – III : Relaciones de Asociación - I
Relación duradera entre un cliente y un servidor

Se dice que una clase A (cliente) está asociada a otra clase B
(servidor) cuando un objeto de la clase A precisa de los servicios de
uno o varios objetos de la clase B para realizar su responsabilidad
asignada.
La relación de asociación establece un grafo en la que las distintas
clases desempeñan funciones de “cliente” para con sus
“servidores” y de “servidor” para con sus “clientes”
Desde el punto de vista de la programación esta relación se
traduce entre la clase y las clases de sus atributos definidos como
punteros a dichas clases.
public class X
{
private x;
public asociacion(X x) {
this.x = x;
}
}

Clases – III : Relaciones de Asociación – II
Características
Visibilidad
• Los objetos asociados a otro objeto no están encapsulados.
• Existen fuera del objeto cliente y tienen vida propia para colaborar
con otros objetos.
Temporalidad
• La relación entre los objetos asociados y el objeto al que se asocian
es duradera en el tiempo.
Versatilidad
• Cada objeto que se asocia está relacionado con unos
“determinados” objetos asociados

Clases – III : Relaciones de Asociación – III
Job 1..∗
Company ∗
employer employee Person
asociación rol
Job boss
salary
0..1 Asociación
“clase asociación” worker ∗ reflexiva
Manages
Instancia solo una de las dos

Person
{X or}
Account
estereotipo Corporation
Fig. 3-40, UML Notation Guide

Clases – III : Relaciones de Asociación – III
Year
season ∗ Asociación ternaria
∗ ∗
Team Player
team goalkeeper
Record
goals for
goals against
wins
losses
ties

Clases – III : Relaciones de Asociación – IV
Multiplicidad
La multiplicidad es la cantidad de objetos de una clase
que se relacionan con un objeto de la clase asociada.

Clases – III : Relaciones de Asociación – V
Asociaciones calificadas
Cuando la multiplicidad de de una asociación es de uno a
muchos se presenta un reto muy particular: la búsqueda
Cuando un objeto de una clase tiene que seleccionar un

objeto particular de otro tipo para cumplir con un papel
en la asociación, la primera clase deberá atenerse a un
atributo en particular para localizar al objeto adecuado
En UML la información de identidad se conoce como

calificador.

Clases – III : Relaciones de Composición – I
Son un tipo especial de

agregación
Los objetos parte siempre Window
están asociados a un objeto
scrollbar [2]: Slider
todo y sólo a uno. title: Header
body: Panel
Los objetos parte se crean y
destruyen con el objeto todo.
Los objetos parte no pueden Window
compartirse entre varios 1
1
objetos todo. 1
scrollbar 2 title 1 body 1
Slider Header Panel

Clases – III: Relaciones de Composición – II
Notación alternativa
Window
2
scrollbar:Slider
1
title:Header
1
body:Panel

Clases – III : Relaciones de Agregación – I
Una relación de agregación es la

que forma un todo con sus
partes.
Son un tipo especial de relación
de asociación.
Pueden tener estereotipos,
nombre, roles, multiplicidad, ...
En las relaciones de agregación,
un objeto que representa una
parte puede estar compartido
por varios objetos que
representan el todo (un alumno
está en un curso y también
puede estar en un grupo de
amigos).

Clases – III : Relaciones de Herencia – I
Regla Generalización/Especialización
La especialización es la presencia de unas características
específicas de un subconjunto de elementos de un
determinado conjunto
Regla ¿ es-un ?

Clases – III : Relaciones de Herencia – II
Shape
Separate Target Style
Polygon Ellipse Spline . ..
Shape
Shared Target Style
...
Polygon Ellipse Spline

Clases – III : Relaciones de Dependencia – I
• Cuando en una relación una clase utiliza a otra, a la
relación se la denomina dependencia
• El uso más común de una dependencia es mostrar que la
signatura de la operación de la operación de una clase utiliza
la otra clase
La clase Sistema tiene la operación mostrarFormulario(f:Form). El

sistema que el usuario desplegrá dependerá del sistema que elija
el usuario.

Clases – III : Relaciones de Dependencia – II
• Un cambio en un elemento puede necesitar un cambio en el otro
• Unos predefinidos : <<use>>, <<import>>
• Otros definidos por el usuario: <<friend>>
ClassA ClassB ClassD

«friend»
«friend»
operationZ()
«instantiate»
«call» ClassC
«refine»
ClassC combines
two logical classes
ClassD ClassE

Clases – III : Relaciones de Dependencia – III
Características
Visibilidad
• Los objetos usados por otros objetos de una clase pueden estar
(declaraciones locales) o no estar encapsulados (parámetros y
valor devuelto por funciones y operadores).
Temporalidad
• La relación entre los objetos usados y el que los usa, dura mientras
se ejecuta un método determinado de la clase cliente.
Versatilidad
• Cada objeto que usa no está relacionado con unos “determinados”
objetos usados (cualquier objeto servidor nos vale).

Clases – III : Relaciones de Dependencia – IV
Entre paquetes
Controller
«access»
«access»
«access» Diagram
Elements
«access»
«access»
Domain Graphics
Elements Core

Clases – IV : Objetos
Se utilizan para mostrar el estado del sistema en un

momento concreto
tria n g le : P olyg on tria ng le

c e n te r = (0 ,0 )
ve rtic e s = ( (0 ,0 ),(4 ,0) ,( 4,3 ))
bo rd e rC olo r = bla c k
fillC o lo r = wh ite
:P olyg on
tria ng le : P o lyg o n
s c h e d u le r

Clases – IV : Objetos compuestos
awindow : Window
horizontalBar:ScrollBar
verticalBar:ScrollBar
moves
surface:Pane
moves
title:TitleBar

Clases – V : Ejemplo I de Diagrama de clases
CreditCard
PMCreditCard
{abstract}
OrderBean
<<interface>> {abstract}
EntityBean
+getOrderStatus
+setOrderStatus
PMOrder
+getLineItems
+setLineItems
order +getCreditApproved
+setCreditApproved
* ...
1 order
buyer 1 * item
Customer LineItem
PMLineItem
{abstract}
*
* item
1 commodity
Product

Clases – V: Ejemplo II de Diagrama de clases

Clases – VI : Tipos e implementación
Un <<type>> define un dominio de objetos y sus operaciones
Sin implementación y sin métodos reales (solo especificaciones)
Una <<ImplementationClass>> realiza el tipo en un lenguaje (Java)
«type» «implementationClass»
Object HashTable
* elements 1 body
«type» «implementationClass»
Set HashTableSet
addElement(Object)
removeElement(Object) addElement(Object)
testElement(Object):Boolean removeElement(Object)
testElement(Object):Boolean
Fig. 3-27, UML Notation Guide setTableSize(Integer)

Clases – VII : Interfaces - I
Especifica las operaciones ( de una clase o un componente):

visibles desde fuera, “que ofrece”, que implementa
que necesita, “que requiere”, que usa
No implementa nada: es un contrato de un “servicio”
Dos modos de representación: simplificada y detallada
Según las necesidades de representación
Simplificada:
StoreHome Store
POSterminalHome -storeId: Integer

-POSlist: List
POSterminal <<use>> +create()
+login(UserName, Passwd)
POSterminal +find(StoreId)
+getPOStotals(POSid)
+updateStoreTotals(Id,Sales)
Store
+get(Item)

Clases – VII : Interfaces – II
<<use>>
realización

Clases – VIII: Cuándo emplear los diagramas de clase
Los diagramas de clase son la columna vertebral de los métodos

OO
Son tan ricos que pueden resultar abrumadores
No tratar de utilizar todas las anotaciones disponibles
• Comenzar con material sencillo como clases, asociación, atributos y
generalización.
Ajustar la perspectiva desde la cual se dibuja los modelos a la etapa
del proyecto Organización y dependencias entre los componentes
software
• Si se está en la etapa de análisis modelos conceptuales
• Cuando se trabaje con software centrarse en los modelos de
especificación
No dibujar modelos para todo
• Centrarse en las áreas clave
• Es mejor usar y mantener al día unos cuantos diseños que tener muchos
modelos olvidados y obsoletos
El principal peligro es que nos podemos quedar muy pronto
empantanados con los detalles de la implementación
• Hay que centrarse en las perspectivas conceptual y de especificación.

Modelo de casos de uso – I
Visión del sistema tal como se muestra a sus usuarios

externos
Los desarrollan tanto los analistas como los expertos del
dominio
Particiona la funcionalidad requerida del sistema en:

transacciones o toma instantánea de algún aspecto del
sistema (casos de uso)
que producen un “valor” para los usuarios (actores)
Muestra los servicios que los actores (usuarios y otros
sistemas) pueden pedir al sistema. Son objetivos del usuario.
Se define mediante:
Diagramas de casos de uso (todo el sistema)
Descripción de los casos de uso
• Mediante plantillas de texto
• Acompañados de diagramas de interacción (ej.: d. secuencia)

Modelo de casos de uso – I
Permite delimitar el sistema y las relaciones entre éste y

su entorno
Similar a los DFD´s en el enfoque Estructurado
El cliente y el equipo de desarrollo conforman un

importante conjunto de integrantes en un sistema. Sin
embargo, existe otro integrante de crucial importancia: el
usuario. Ni la idea estática ni la dinámica mostrarán el
comportamiento del sistema desde el punto de vista del
usuario. Comprender tal punto de vista es clave para
generar sistemas que sean tanto útiles como funcionales,
esto es, que cumplan los requerimientos y que sea fácil de
trabajar con ellos.
Facilitan la comunicación entre el analista y el usuario.

Modelo de casos de uso – II: elementos
Elementos de un diagrama de casos de uso

Caso de uso
• Secuencia de acciones, incluyendo variantes,
que puede realizar el sistema interaccionando nombre de
caso de uso
con los actores del sistema
Actor
• Un conjunto coherente de roles que juegan los usuarios
cuando interaccionan con los casos de
uso
• Cualquier cosa con comportamiento nombre de actor
• (hardware,software, personas)
Límite del sistema (frontera)
• Representa el límite entre el sistema físico y
los actores que interaccionan con el sistema

Modelo de casos de uso – III: relaciones entre elementos
Relaciones en un diagrama de casos de uso

Asociación
• La participación de un actor en un caso de uso
• La instancia de un actor se comunican con instancias de un
caso de uso
Generalización (es_un)
• Relación taxonómica entre un caso de uso más general y
otro más específico (también se aplica a actores)
Dependencia
• <<extend>> el primero es una función opcional del
segundo (variación o punto de extensión). Se utiliza
cuando se tiene un caso de uso que es similar a otro pero <<extend>>
que hace un poco más.
• <<include>> el primero hace una llamada obligatoria al
segundo. Ocurre cuando se tiene una porción de
comportamiento que es similar en más de un caso de uso y <<include>>
no se quiere copiar la descripción de tal conducta.
Utilícese extend uando se describa una variación de conducta
normal
Emplése include cuando se dese evitar repeticiones

Diagramas de casos de uso - I
Asociaciones de dependencia y generalización
<<extend>>
el cliente solicita
el catálogo
Solicitar catálogo Realizar pedido
<<include>> <<include>>
<<include>>
Proporcionar Datos Pedir Producto Realizar Pago

Cliente
Pago en metálico Pago con tarjeta de

crédito

Diagrama de casos de uso – II
Es más importante realizar las descripciones de los casos

de uso que el diagrama de casos de uso
Los casos de uso son documentos de texto
Trabajar con los casos de uso significa escribir texto
Los diagramas de casos de uso tienen que ser sencillos
Ayudan a determinar el contexto, los límites del sistema

Diagrama de casos de uso – III: Cuándo definirlo
Para identificar los requisitos funcionales del sistema

y para identificar escenarios de prueba
y el contexto o límites
Normalmente en las primeras etapas de desarrollo
En metodologías dirigidas por casos de uso:
• Empezar por los casos de uso y derivar de ellos los modelos
estructural y de comportamiento
y si no:
• Asegurarse que el modelo de casos de uso es consistente con los
modelos estructural y de comportamiento

Diagrama de casos de uso – IV
CENTROS HOSPITALARIOS
Un cierto hospital necesita organizar la asignación de guardias de sus médicos en sus

diferentes centros hospitalarios mediante una aplicación informática. Para ello asigna a un
Analista el diseño del sistema utilizando la notación UML.
Un médico jefe tiene asignada la función de Planificador de guardias y debe tener en

cuenta los médicos disponibles, las guardias que debe cubrir y algunas incompatibilidades
como asignaciones de tareas de más alta prioridad.
Por otra parte, los datos de todos los médicos los mantiene un Supervisor, encargado de
mantener esta información: altas, bajas, cambios de datos, etc.
Existe también un Administrador del sistema que se encarga de la asignación y

revocación de permisos a los planificadores.
Se desea, asimismo, disponer de una función estadística que permita generar listados
informativos.
Dado que varios planificadores de guardias pueden trabajar en paralelo, se quiere que se
actualicen automáticamente las estadísticas que vea cada uno cada vez que haya un
cambio por parte de cualquiera de ellos. Asimismo, cada planificador puede editar y
modificar planes de guardias.
Se pide realizar el Diagrama de Casos de Uso de la aplicación. Realizar una descripción

textual de los casos de uso y actores contemplados.
Diagrama de casos de uso – V
CENTROS HOSPITALARIOS
Solución:
Los casos de uso son:
Gestionar Médicos: dar de alta, de baja y cambio de datos a todos los médicos
de cada centro hospitalario.
Gestionar Estadísticas: actualizar las Estadísticas y presentarlas a los usuarios
de la aplicación cuando lo soliciten.
Editar Planes: asignar los médicos disponibles a las guardias previstas.
Gestionar Planes: creación y borrado de planes, apertura y cierre de planes ya
creados, edición e impresión (por ello se incluye al anterior “Editar Planes”)
Gestionar Usuarios: gestionar las cuentas de los planificadores de guardias
autorizados, creando usuarios y asignándoles una palabra clave.
Los actores son:
Supervisor: empleado administrativo que trabaja con datos confidenciales y que

tiene que tener permisos especiales de acceso a datos restringidos.
Planificador: encargado de la asignación de guardias teniendo en cuenta la
restricciones introducidas previamente en el sistema por el Supervisor
Administrador: responsable de la asignación de cuentas de acceso y de asegurar
la confidencialidad y la integridad de la información del sistema.

Diagrama de casos de uso – VI

Caso de uso – I : Pautas a seguir para un buen modelo
Asegurarse que cada caso de uso describe una parte

significativa del funcionamiento del sistema
Evitar un número excesivo de casos de uso
Un caso de uso no es un paso, operación o actividad
individual en un proceso
Un caso de uso describe un proceso completo que incluye
varios pasos (flujo de trabajo de la empresa)
Los casos de uso deben ser simples, dado que podrían

cambiar con facilidad
Los casos de uso tienen que ser entendibles tanto por
desarrolladores software como por expertos del dominio
Es una descripción de alto nivel del sistema
Evitar conceptos de diseño

Caso de uso - II : Identificarlos para un buen modelo
A partir de los actores

Qué actores? (relacionados con el sistema o organización)
• quién necesita el sistema?
• qué necesita el sistema para funcionar: personal, hardware
especializado, otros programas (software).
Para cada actor, identificar los procesos que inician o en los que
participan
• ponerle nombre
• determinar límites/frontera: qué es del sistema? Qué queda fuera?
• Qué espera recibir/obtener?
A partir de los eventos
Identificar los eventos externos a los que puede responder el
sistema
Relacionar los eventos con actores y casos de uso

Caso de uso - III : Descubrimiento
1. Determinar los límites del sistema

¿Es sólo una aplicación software, el hardware y la aplicación como
un todo?
¿Lo utiliza más de una persona o una organización completa?
2. Identificar los actores principales
• Quienes interactúan con el sistema
3. Para cada actor, identificar sus objetivos como usuario
• Seguir “flujos” en la empresa: dinero, información,…
4. Definir los casos de uso que satisfagan los objetivos de
usuario
• Nombrar los casos de uso con un verbo

Caso de uso – IV : Descripción usando Plantillas
Caso de Uso <número> nombre: objetivo/frase verbal corta
Objetivo: Frase de definición del objetivo
Precondiciones: Estado Mundo: cuándo y cómo se activa. Datos

entradas: entrada
Post-condiciones:
salidas:
Condición final exitoso: El estado del mundo si todo va bien (y datos salida)
El estado del mundo si se abandona el objetivo
Condición final fallido:
Actor primario: Nombre del rol que interactúa con el sistema
Actores secundarios: Otros sistemas que pueden participar
Secuencia normal: Paso Acción
(acciones actores si todo bien) 1 Pasos del escenario
2
Extensiones: Paso Acción
flujos alternativos,
excepciones
1a Condición que causa la alternativa:
Acción o nombre del subcaso
Caso de uso - V : D. Casos Uso en el proceso Análisis
Las entrevistas con el cliente inician el proceso

Estas entrevistas producirán diagramas de clases
• Obtendremos la base de conocimiento para el dominio del sistema, esto
es, el área del cliente
Ahora se está en condiciones de poder hablar con el usuario
Las entrevistas con el usuario empiezan con la
terminología del dominio, aunque deberán alternarse
hacia la terminología de los usuarios
Estas entrevistas desvelarán a los actores y casos de uso de
alto nivel que descubrirán los requerimientos funcionales en
términos generales
Esta información también permitirá establecer los límites y
ámbito del sistema
Entrevistas posteriores con el usuario
Permitirán profundizar en los requerimientos, lo que dará
lugar a casos de uso que mostrarán los escenarios y las
secuencias detalladamente

Caso de uso - V : D. Casos Uso en el proceso Análisis
Entrevistas posteriores con el usuario (cont.)

Esto podría resultar en otros casos de uso que satisfagan las
relaciones de inclusión y extensión.
En esta fase es importante confiar en la compresión del
dominio a partir de los diagramas de clase
• Si no se comprende adecuadamente el dominio se podrían crear
demasiados casos de uso y demasiados detalles, lo cual
obstaculizaría la labor de diseño.

Bibliografía
[UML 2.0] Unified Modeling Language: Superstructure v 2.0 (ago2005)

http://www.omg.org/cgi-bin/doc?formal/05-07-04
G. Booch, J. Rumbaugh, I. Jacobson, El Lenguaje Unificado de Modelado(UML

2.0) 2ª Edición. Addison Wesley, 2006.
[UML 1.5] OMG Unified Modeling Language Specification v. 1.5, Marzo 2003.
OMG UML: www.omg.org/uml
También www.uml.org
Cetus links: www.cetus-links.org/oo_uml.html


02uml 1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

02uml 1

Cargado por

Copyright:

Formatos disponibles

UML

Diagramas de Clases y Casos de Uso

Ingeniería del Software 2

Prof.:Juan Carlos Gutiérrez Lázaro

Dep. Ingeniería del Software e Inteligencia Artificial

Unified Modelling Language

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Unified Modelling Language

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

No es el objetivo (... Aplicación robusta flexible y escalable

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Modelo de la arquitectura de un sistema

4+1 Vistas => Diagramas <= UML

Vista Diseño Vista Implementación

Cada vista es una proyección de la organización y

Vista de Casos de Uso: incluye los casos de uso que describen

Vista de Diseño: incluye las clases, interfaces y colaboraciones

Vista de Implementación: incluye los componentes que se

Vista de Despliegue: incluye los nodos que forman la topología

Vista de Procesos: incluye los hilos y procesos que forman los

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Definir un lenguaje de modelado visual fácil de aprender

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Metodología de desarrollo de software OO

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Permite estructurar la solución a un problema

Notación gráfica: Gráficos revelan la información

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Son los nombres de los modelos UML y representan

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Caso de uso: descripción de un conjunto de secuencias de

Clase: descripción (abstracción lógica) de un conjunto de

Interfaz: colección de operaciones que especifican un servicio

Colaboración: define una interacción y es una sociedad de

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Componente: parte modular del diseño del sistema que

Nodo: es un elemento físico que existe en tiempo de

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Paquete: es un mecanismo de propósito general para

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Representan las partes dinámicas de los modelos UML,

Mientras que las ideas estáticas ayudan a que un analista

Existen tres tipos de elementos de comportamiento:

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Interacción: conjunto de mensajes intercambiados entre

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Máquina de estados: comportamiento que especifica la

Actividad: comportamiento que especifica la secuencia

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Interacción conjunto de objetos que interactúan

Máquina de estados ciclo de vida de un objeto

Actividad flujo entre los pasos ya sea de datos

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Son los elementos explicativos del modelo UML

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Héctor Gómez Gauchía (adapt.de Juan Pavón) UML

Modelado Casos de Uso Modelado Estructural

Diagramas de Casos de Uso Diagramas de Clases

Modelado de Comportamiento Modelado de Implementación

Diagramas de Secuencia Diagramas de Componentes