UNIVERSIDAD NACIONAL MICAELA BASTIDAS DE APURÍMAC

CARRERA PROFESIONAL DE INGENIERÍA INFORMÁTICA y

SISTEMAS

Análisis Diseño de Sistemas de Información II

Docente: Ing. Sist. Ángel Fernando Navarro Raymundo

Jefe de Practica: Ing. Sist. Wilfredo Soto Palomino

UML y Casos de Uso

I.- OBJETIVOS
✔ Diagramar Casos de Uso
✔ Identificar los tipos de casos de uso
✔ Manejar los formatos de casos de uso

II.- TEMAS A TRATAR

✔ Introducción a UML
✔ Vista de Casos de Uso
✔ Diagrama de Casos de Uso

III.- MARCO TEORICO

INTRODUCCIÓN A UML

El lenguaje unificado de modelado o UML (Unified Modeling Language) es el sucesor de la

oleada de métodos de análisis y diseño orientados a objetos que surgió a finales de la década
de 1980 y comienzos de los ‘90s.

UML es un lenguaje de modelado, y no un método. La mayor parte de los métodos consisten,

al menos en principio, en un lenguaje y en un proceso para modelar. El lenguaje de
modelado es la notación (principalmente gráfica) de que se valen los métodos para expresar
los diseños. El proceso es la orientación que nos dan sobre los pasos a seguir para hacer el
diseño.

Es posible identificar 3 generaciones de notaciones propuestas para el desarrollo de POO:

• Primera generación
Denominada la “guerra de los métodos”, aparecieron una gran cantidad de notaciones
diferentes. No fue hasta la popularización de lenguajes como Smalltalk y C++, a
finales de los 80, que empezó a necesitarse una metodología para el desarrollo de
POO. Entre 1989 y 1994, el número de métodos y notaciones pasó de 10 a 50, entre
los que se destacaron OMT(Object Modeling Technique) de Rumbaugh; el método de
Booch; OOSE/Objectory (Object-Oriented Software Engineering) de Jacobson;
Coad/Yourdon; Shaler/Mellor; HOOD(Hierarchical Object+Oriented Design) ; y
ROOM(Real Time Object-Oriented Modeling) .

La mayoría de los métodos y notaciones sólo cubría una de las actividades del desarrollo, por
ejemplo el diseño.

• Segunda generación
 Los métodos empiezan a converger. Los autores reúnen las conceptos de varias de las
técnicas propuestas con la finalidad de ofrecer un soporte integral para todo el ciclo de
vida. Aparece Fusion, la segunda versión de OOSE, OMT-2 y Booch’93.

• Tercera generación
UML define la notación cubriendo todo el ciclo de desarrollo y diversos dominios de
aplicación.

La historia de UML empieza en 1994 cuando Booch y Rumbaugh , trabajando para una
empresa productora de herramientas de programación llamada Rational, deciden juntar sus
trabajos para proponer el “Unified Method”, presentando la primera versión en octubre de
1995.

Luego se les une Jacobson, que trabajaba en Ericsson. Este equipo de trabajo se le conoce
como el de “los tres amigos”; quienes adoptan para su obra el nombre de UML y entregan
dos versiones en 1996, al igual que su propia herramienta de soporte: Rational Rose.

Mas adelante, convocan a integrar el consorcio UML a grandes empresas del mundo de la
informática como son: Digital Equipment Corporation, HP, IBM, Microsoft, Oracle, Unisys,
Texas Instruments, Rational y otros más. En 1997, se presenta la versión 1.0, al proceso de
adopción de normas de la OMG (Object Managment Group).

UML representa la unificación de las notaciones de Booch, OMT y Objectory, al igual que
las mejores ideas de otros metodologistas.
VISTAS
La descripción de los sistemas se realiza en UML a través de Vistas, las cuales a su vez están
integradas por diagramas. Esto se debe a que un diagrama no puede expresar toda la
información que se requiere para describir un sistema. Similar a la construcción de un
edificio; en un plano no pueden estar todos los detalles, se elaboran varios planos
representando diferentes aspectos del edificio.

Tenemos las siguientes vistas consideradas en UML:

VISTA DE CASOS DE USO

No es casual que en la figura anterior, la Vista de Casos de Uso se represente en el centro de
todas, haciendo el papel de enlace, pues ésta constituye el hilo conductor de todo el proceso
de desarrollo. Muestra la funcionalidad del sistema, tal como es percibida por actores
externos.

La Vista de Casos de Uso es utilizada por todos los participantes en el proceso de desarrollo:
los clientes, pues a través de ella se definen y se expresan los requerimientos del sistema; y
los equipos de diseño, desarrollo y pruebas.

Utiliza los siguientes diagramas:

✔ Diagramas de Casos de Uso
✔ Diagramas de Actividad (opcional)
DIAGRAMA DE CASOS DE USO

Sirve para describir las interacciones del sistema con su entorno, identificando los Actores,
que representan los diferentes roles (la labor que desempeña frente al sistema) desempeñados
por los usuarios del sistema, y los Casos de Uso, que corresponden a la funcionalidad que el
sistema ofrece a sus usuarios , explicada desde el punto de vista de estos. Los actores no son
solamente humanos, pudiendo ser también otros sistemas con los cuales el sistema en
desarrollo interactúa de alguna manera.

Actor

Un actor es una idealización de una persona externa, de
interactúa con un sistema, un subsistema, o una clase. En
físico puede estar limitado a los actores múltiples dentro
pueden estar ligados al mismo actor y por lo tanto pueden
misma definición de actor.
un proceso, o de una cosa que
tiempo de ejecución, un usuario
del sistema. Diferentes usuarios
representar casos múltiples de la

Cada actor participa en uno o más casos de uso. Pueden ser definidos en jerarquías de
generalización. Se dibuja a un actor como una persona pequeña con trazos lineales y el
nombre debajo de él.

Casos de Uso

Un caso de uso es una unidad coherente de funcionalidad, externamente visible,

proporcionada por una unidad del sistema y expresada por secuencias de mensajes
intercambiados por la unidad del sistema y uno o más actores.

En el modelo la ejecución de cada caso de uso es independiente de las demás, aunque una
implementación de casos de uso puede crear dependencias implícitas entre ellas, debido a los
objetos compartidos.

La dinámica de un CU se puede especificar en los diagramas de estado, de secuencia, de

colaboración, o descripciones informales de texto.

Es una descripción lógica de una parte de funcionalidad del sistema. Cada CU se debe
corresponder con las clases que implementan un sistema. El comportamiento del CU se
corresponde con las transiciones y operaciones de las clases. Puede participar en varias
relaciones.

Un CU se dibuja como una elipse con su nombre dentro o debajo de ella.

Entre los actores y los CU se establecen asociaciones que se representa mediante una línea
sólida e indican cuáles actores participan en un CU. Todo CU tiene siempre un actor que lo
“dispara”, denominado iniciador, siendo conveniente identificarlo en los CU que tienen
varios actores usando la palabra “iniciador” o mediante una flecha.

Entre los CU también se pueden establecer relaciones los cuales son de dos tipos:

a) Inclusión: representada por una flecha con línea discontinua etiquetada con el estereotipo
<<include>>. Una relación de inclusión desde el caso de uso A hacia el caso de uso B, indica
que el comportamiento descrito en el caso de uso B es incluido en el caso de uso A.

Disponer <<include>>

<<include>> Autentificar Cliente

Realizar Pago

b) Extensión : representada por una flecha discontinua, etiquetada con el estereotipo

<<extend>>. Una relación de Extensión desde un caso de uso A hacia un caso de uso B,
indica que el caso de uso B puede incluir (condicionado al cumplimiento de condiciones
específicas establecidas en la extensión) el comportamiento del caso de uso A.

Realizar llamada
Llamada a Cobro Revertido
<<extend>>

Ejemplo de Casos de Uso

 Genero reporte diario
Cliente
Depositar I tem

Cam biar I tem Operador

Tipos de casos de uso y formatos

Según el nivel de abstracción:
a) Casos de Uso Abstractos: describen las interacciones de manera ideal, abstrayendo los
detalles de tecnología de implementación , especialmente aquellos relacionados con las
interfaces de usuario.

b) Casos de Uso Reales: Describen las interacciones en términos de su diseño real,

incluyendo los detalles de las tecnologías empleadas en las entradas y las salidas

Según el nivel de detalle en su descripción:

a) Casos de Uso de Alto Nivel: Describen las interacciones muy brevemente, usando 2 o 3
frases. Utilizados en las fases iniciales de captura de requerimientos con el fin de obtener una
visión rápida de la funcionalidad Ejemplo:

El Tipo representa el nivel de importancia, y sirve de base para establecer un orden de

prioridad en el momento de planificar su implementación. Los tipos son:
✔ Primario: representa una interacción principal y común en el sistema
✔ Secundario: representa una interacción menor o de rara ocurrencia
✔ Opcional: representa una interacción que puede no ser abordada

b) Casos de Uso Extendidos: Describen las interacciones con mayor detalle que los de alto
nivel, enumerando paso a paso los eventos que se presentan durante una ocurrencia:
Ejemplo:
...... Postcondiciones
...... Flujo Principal
...... Flujos AlternativosPrecondiciones

Observaciones:

✔ En la información general, cuando se declaran los actores, debe señalarse cual es el actor
iniciador del caso de uso.
✔ En el resumen puede usarse la descripción del caso de uso de alto nivel correspondiente.
✔ Las referencias cruzadas indican con cuáles funciones del sistema y casos de uso existe
relación.
✔ Precondiciones denotan las condiciones que deben cumplirse al momento de invocar a las
operaciones o funciones.
✔ Postcondiciones denotan las condiciones que deben cumplirse después de haber invocado
a las operaciones o funciones.
✔ El Flujo Principal o Básico debe comenzar con la frase “Este caso de uso empieza cuando
el actor...” mencionando el iniciador.
✔ Los Flujos Alternativos describen situaciones excepcionales.

Hay varias plantillas disponibles para los casos de uso Extendidos o Completos. Quizás el
formato más ampliamente extendido y compartido es la plantilla disponible en
http://alistair.cockburn.us/usecases/usecases.html.

IV ACTIVIDADES
(La práctica tiene una duración de 02 horas)

Antes de dar solución a los siguientes planteamientos, las siguientes preguntas ayudarán a
identificar los actores y los casos de uso para un sistema:

Actores:

✔ Quién está interesado en un cierto requerimiento?

✔ En que parte de la organización es o será el sistema usado?
✔ Quién se beneficiará con el uso del sistema?
✔ Quién proporcionará la información, la usará y la removerá del sistema?
✔ Quién hará el soporte y el mantenimiento del sistema?
✔ Una persona desempeña diferentes roles?
✔ Varias personas desempeñan el mismo rol?
✔ El sistema interactúa con algún otro sistema?
Casos de Uso

✔ Cuáles son las tareas de cada actor?

✔ Algún actor crea, almacena, cambia, remueve, o lee información en el sistema?
✔ Qué caso de uso creará, almacenará, cambiará, removerá, o leerá esta información?
✔ Algún actor necesita ser informar al sistema acerca de repentinos cambios externos?
✔ Algún actor necesita ser informado acerca de ciertas ocurrencias en el sistema?
✔ Que casos de uso soportarán y mantendrán el sistema?

01. Indique los errores en el siguiente Diagramas de Casos de Uso

Validar Datos

Usuario

Imprimir Nombre

02. Diagrame el Caso de Uso del caso de una persona con un control remoto de televisor.

03. Desarrolle el siguiente caso:

Suponga que se tiene un Sistema de Registros de Cursos. Un asistente de enseñanza es la
persona que recibe clases e imparte clases. Se tiene además los siguientes hechos:
✔ Estudiantes desean registrarse en cursos.
✔ Profesores desean seleccionar cursos a enseñar.
✔ El Registrador debe crear el programa de estudios y generar un catálogo para el semestre.
✔ El Registrador debe mantener toda la información acerca de cursos, profesores y
estudiantes.
✔ El Sistema de Pago debe recibir la información de pagos del sistema

a) Basado en los anteriores hechos identifique los actores

b) Una vez identificados los actores, realice una breve descripción de cada uno de ellos en el
modelo
Las siguientes necesidades deben ser atendidas por el sistema:

✔ El Estudiante necesita usar el sistema para registrarse a los cursos.

✔ Luego que el proceso de selección del curso es completado, El Sistema de Pago debe
proporcionar la información de pago.
✔ El Profesor necesita usar el sistema para seleccionar los cursos a enseñar en el semestre, y
debe ser capaz de recibir un registro del curso del sistema.
✔ El Registrador es responsable de la generación del catálogo del curo por semestre, y del
mantenimiento de toda la información acerca del programa de estudios, los estudiantes y
de los profesores.
c) Basado en estas necesidades, identifique los casos de uso.
d) Una vez identificados los casos de uso, realice una breve descripción de c/u de ellos en el
modelo.

Realizando las consistencias necesarias y describa algunos casos de uso del modelo de
acuerdo al formato dado. Considere que se valida al usuario al usar el sistema.

Elabore el diagrama de casos de uso estableciendo las relaciones necesarias entre cada
elemento del diagrama.
04. Tome el ejemplo anterior y aplíquelo en su caso de estudio.