UDI ** Modelado De Sistemas ** Ing. Víctor Uribe O.

Documentos Tomados De Internet

Diagramas de Caso de Uso
Casos de Uso es una técnica para capturar información de cómo un sistema o negocio
trabaja, o de cómo se desea que trabaje. No pertenece estrictamente al enfoque orientado a
objeto, es una técnica para captura de requisitos.

 Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el
comportamiento de un sistema desde el p.d.v. del usuario.
 Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno.
 Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la
implementación.
 Comparación con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado.
 Los Casos de Uso cubren la carencia existente en métodos previos (OMT, Booch) en
cuanto a la determinación de requisitos.
 Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categoría de
usuarios que participan en el mismo.
 Están basados en el lenguaje natural, es decir, es accesible por los usuarios.

Actores
 Principales: personas que usan el sistema.
 Secundarios: personas que mantienen o administran el sistema.
 Material externo: dispositivos materiales imprescindibles que forman parte del
ámbito de la aplicación y deben ser utilizados.
 Otros sistemas: sistemas con los que el sistema interactúa.

La misma persona física puede interpretar varios papeles como actores distintos, el
nombre del actor describe el papel desempeñado.
Los Casos de Uso se determinan observando y precisando, actor por actor, las
secuencias de interacción, los escenarios, desde el punto de vista del usuario. Los
casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estará
dirigido por los casos de uso. Un escenario es una instancia de un caso de uso.

1
 UDI ** Modelado De Sistemas ** Ing. Víctor Uribe O.
Documentos Tomados De Internet
UML define cuatro tipos de relación en los Diagramas de Casos de Uso:
 Comunicación
 Inclusión : una instancia del Caso de Uso origen incluye también el comportamiento
descrito por el Caso de Uso destino. «include» reemplazó al denominado «uses»
 Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino.
«extend»
 Herencia : el Caso de Uso origen hereda la especificación del Caso de Uso destino y
posiblemente la modifica y/o amplía.

Parámetros para la construcción de un caso de uso:

Un caso de uso debe ser simple, inteligible, claro y conciso. Generalmente hay pocos actores
asociados a cada Caso de Uso. Preguntas clave:

1. cuáles son las tareas del actor?

2. qué información crea, guarda, modifica, destruye o lee el actor?
3. debe el actor notificar al sistema los cambios externos?
4. debe el sistema informar al actor de los cambios internos?

La descripción del Caso de Uso comprende:

1. el inicio: cuándo y qué actor lo produce?
2. el fin: cuándo se produce y qué valor devuelve?
3. la interacción actor-caso de uso: qué mensajes intercambian ambos?
4. objetivo del caso de uso: qué lleva a cabo o intenta?
5. cronología y origen de las interacciones
6. repeticiones de comportamiento: qué operaciones son iteradas?
7. situaciones opcionales: qué ejecuciones alternativas se presentan en el caso de uso?

2
 UDI ** Modelado De Sistemas ** Ing. Víctor Uribe O.
Documentos Tomados De Internet
Diagrama de Actividades

El Diagrama de Actividad es una especialización del Diagrama de Estado, organizado respecto de

las acciones y usado para especificar:

 Un método
 Un caso de uso
 Un proceso de negocio (Workflow)

Un estado de actividad representa una actividad: un paso en el flujo de trabajo o la ejecución de

una operación. Un grafo de actividades describe grupos secuenciales y concurrentes de
actividades. Los grafos de actividades se muestran en diagramas de actividades. Las actividades
se enlazan por transiciones automáticas. Cuando una actividad termina se desencadena el paso
a la siguiente actividad.

Un diagrama de actividades es provechoso para entender el comportamiento de alto nivel de la

ejecución de un sistema, sin profundizar en los detalles internos de los mensajes. Los
parámetros de entrada y salida de una acción se pueden mostrar usando las relaciones de flujo
que conectan la acción y un estado de flujo de objeto.

Un grafo de actividades contiene estados de actividad que representa la ejecución de una

secuencia en un procedimiento, o el funcionamiento de una actividad en un flujo de trabajo. En
vez de esperar un evento, como en un estado de espera normal, un estado de actividad espera

3
 UDI ** Modelado De Sistemas ** Ing. Víctor Uribe O.
Documentos Tomados De Internet
la terminación de su cómputo. Cuando la actividad termina, entonces la ejecución procede al
siguiente estado de actividad dentro del diagrama. una transición de terminación es activada
en un diagrama de actividades cuando se completa la actividad precedente. Los estados de
actividad no tienen transiciones con eventos explícitos, peor pueden ser abortados por
transiciones en estados que los incluyen.

Un grafo de actividades puede contener también estados de acción, que son similares a los de
actividad pero son atómicos y no permiten transiciones mientras están activos. Los estados de
acción se deben utilizar para las operaciones cortas de mantenimiento.

Un diagrama de actividades puede contener bifurcaciones, así como divisiones de control en

hilos concurrentes. los hilos concurrentes representan actividades que se pueden realizar
concurrentemente por los diversos objetos o personas. La concurrencia se representa a partir
de la agregación, en la cual cada objeto tiene su propio hilo. Las actividades concurrentes se
pueden realizar simultáneamente o en cualquier orden. Un diagrama de actividades es como un
organigrama tradicional, excepto que permite el control de concurrencia además del control
secuencial.

4
 UDI ** Modelado De Sistemas ** Ing. Víctor Uribe O.
Documentos Tomados De Internet

Un estado de actividad se representa como una caja con los extremos redondeados que
contiene una descripción de actividad. Las transacciones simples de terminación se muestran
como flechas. Las ramas se muestran como condiciones de guarda en transiciones o como
diamantes con múltiples flechas de salida etiquetadas. Una división o una unión de control se
representa con múltiples flechas que entran o salen de la barra gruesa de sincronización.

Cuando es necesario incluir eventos externos, la recepción de un evento se puede mostrar

como un disparador en una transición, o como un símbolo especial que denota la espera de una
señal.
A menudo es útil organizar las actividades en un modelo según su responsabilidad. Esta clase
de asignación puede mostrarse organizando las actividades en regiones distintas separadas por
líneas en el diagrama. Debido a su aspecto, esto es conocido como Calles.

Un diagrama de actividades puede mostrar el flujo de objetos como valores. Para un valor de
salida, se dibuja una flecha con línea discontinua desde la actividad al objeto. Para un valor de
entrada, se dibuja una flecha con línea discontinua desde el objeto a una actividad.

5
 UDI ** Modelado De Sistemas ** Ing. Víctor Uribe O.
Documentos Tomados De Internet
Modelo de Clases
Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el
sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.

Un diagrama de clases esta compuesto por los siguientes elementos:

Clase: atributos, métodos y visibilidad.
Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

ELEMENTOS

o Clase
Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una
instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un
Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectángulo que posee tres divisiones:

En donde:
Superior: Contiene el nombre de la Clase

Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase

(pueden ser private, protected o public).
Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa
el objeto con su entorno (dependiendo de la visibilidad: private, protected o
public).

Ejemplo:
Una Cuenta Corriente que posee como característica: Balance
Puede realizar las operaciones de: Depositar, Girar y Balance

El diseño asociado es:

o Atributos y Métodos:

Atributos:
Los atributos o características de una Clase pueden ser de tres tipos, los que definen el
grado de comunicación y visibilidad de ellos con el entorno, estos son:

6
 UDI ** Modelado De Sistemas ** Ing. Víctor Uribe O.
Documentos Tomados De Internet

public (+, ): Indica que el atributo será visible tanto dentro como fuera de la clase, es
decir, es accsesible desde todos lados.

private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo
sus métodos lo pueden accesar).

protected (#, ): Indica que el atributo no será accesible desde fuera de la clase, pero
si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver
herencia).

Métodos:
Los métodos u operaciones de una clase son la forma en como ésta interactúa con su
entorno, éstos pueden tener las características:

public (+, ): Indica que el método será visible tanto dentro como fuera de la clase, es
decir, es accsesible desde todos lados.

private (-, ): Indica que el método sólo será accesible desde dentro de la clase (sólo
otros métodos de la clase lo pueden accesar).

protected (#, ): Indica que el método no será accesible desde fuera de la clase, pero
si podrá ser accesado por métodos de la clase además de métodos de las subclases que se
deriven (ver herencia).

o Relaciones Entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden
interrelacionar dos o más clases (cada uno con características y objetivos diferentes).

Antes es necesario explicar el concepto de cardinalidad de relaciones. En UML, la

Cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en
cada extremo de la relación y éstas pueden ser:
uno o muchos: 1..* (1..n)
0 o muchos: 0..* (0..n)
número fijo: m (m denota el número).

1. Herencia (Especialización/Generalización):
Indica que una subclase hereda los métodos y atributos especificados por una Super Clase,
por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las
características y atributos visibles de la Super Clase (public y protected).

Ejemplo: En la figura se especifica que Auto y Camión heredan de Vehículo, es decir, Auto
posee las Características de Vehículo (Precio, VelMax, etc) además posee algo particular
que es Descapotable, en cambio Camión también hereda las características de Vehiculo
(Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.

Cabe destacar que fuera de este entorno, lo único "visible" es el método Características
aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición publica, en cambio
atributos como Descapotable no son visibles por ser privados.

7
 UDI ** Modelado De Sistemas ** Ing. Víctor Uribe O.
Documentos Tomados De Internet

2. Agregación:
Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los
lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer
objetos que son instancias de clases definidas por el desarrollador de la aplicación,
tenemos dos posibilidades:

Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto
incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de
relación es comunmente llamada Composición (el Objeto base se contruye a partir
del objeto incluido, es decir, es "parte/todo").

Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del

objeto incluido es independiente del que lo incluye. Este tipo de relación es
comunmente llamada Agregación (el objeto base utiliza al incluido para su
funcionamiento).
Un Ejemplo es el siguiente:

En donde se destaca que:

Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las
referencias).

8
 UDI ** Modelado De Sistemas ** Ing. Víctor Uribe O.
Documentos Tomados De Internet
Cuando se destruye el Objeto Almacén, también son destruidos los objetos Cuenta
asociados, en cambio no son afectados los objetos Cliente asociados.

La composición (por Valor) se destaca por un rombo relleno.

La agregación (por Referencia) se destaca por un rombo transparente.

La flecha en este tipo de relación indica la navegabilidad del objeto referenciado. Cuando
no existe este tipo de particularidad la flecha se elimina.

3. Asociación:
La relación entre clases conocida como Asociación, permite asociar objetos que colaboran
entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un
objeto no depende del otro.

Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de
compra solo puede tener asociado un cliente.

4. Dependencia o Instanciación (uso):

Representa un tipo de relación muy particular, en la que una clase es instanciada (su
instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

El uso más particular de este tipo de relación es para denotar la dependencia que tiene una
clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la
creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el
objeto Aplicacion):

Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena
dentro del objeto que lo crea (en este caso la Aplicación).