Universidad

Universidad PeruanaPeruana de Ciencias

de Ciencias Aplicadas
Aplicadas

Ingeniera de requerimientos

Modelo de casos de uso del sistema

 Ingeniera de requerimientos

Todos los derechos de propiedad intelectual de esta obra pertenecen en exclusiva a

la Universidad Peruana de Ciencias Aplicadas. Queda terminantemente prohibida la
reproduccin, puesta a disposicin del pblico y en general cualquier otra forma de
explotacin de toda o parte de la misma. La utilizacin no autorizada de esta obra, as
como los perjuicios ocasionados en los derechos de propiedad intelectual e industrial
de la Universidad Peruana de Ciencias Aplicadas., darn lugar al ejercicio de las
acciones que legalmente le correspondan y, en su caso, a las responsabilidades que de
dicho ejercicio se deriven.

2
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

ndice del tema

Introduccin al curso ..................................................................................................................... 5

Logros de aprendizaje ................................................................................................................... 6
Encontrar los actores y casos de uso del sistema ........................................................................ 7
Anlisis del modelo de casos de uso del negocio..................................................................... 7
Identificar actores del sistema ................................................................................................... 7
Dnde encontrar a los actores del sistema? ........................................................................... 7
Otros elementos que ayudan a encontrar a los actores del sistema. ....................................... 9
Sugerencias para identificar adecuadamente a los actores del sistema. ................................. 9
Ejemplo: Un actor representa varias instancias. ....................................................................... 9
Una persona representa el rol de varios actores .................................................................... 10
Relacin entre actor del sistema, usuario y rol ....................................................................... 10
Identificar casos de uso de sistema ........................................................................................ 11
Dnde encontrar casos de uso del sistema? ........................................................................ 11
Sugerencias de identificacin .................................................................................................. 12
Orientaciones de los casos de uso del sistema ...................................................................... 12
Repercusiones en la arquitectura del sistema ........................................................................ 13
Mantenibilidad ..................................................................................................................... 13
Modificabilidad ..................................................................................................................... 14
Escalabilidad ....................................................................................................................... 14
Portabilidad .......................................................................................................................... 14
Cmo afrontar cambios? ....................................................................................................... 14
Cmo afrontar los cambios? Orientados al objetivo ............................................................. 15
Consideraciones ...................................................................................................................... 15
Identificar los paquetes del sistema ............................................................................................ 17
Encontrar los diferentes mdulos del sistema ........................................................................ 17
Cmo definir los paquetes del sistema? ............................................................................... 17
Identificar la dependencia entre los paquetes ......................................................................... 18
Diagrama de Paquete del sistema. Ejemplo ........................................................................... 18
Construir el Modelo de casos de uso del sistema ....................................................................... 19
Asociaciones actores y casos de uso del sistema .................................................................. 19
Diagrama de Casos de Uso del sistema ................................................................................. 20
Conclusiones ............................................................................................................................... 21
Bibliografa................................................................................................................................... 22

3
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

4
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Introduccin al curso

El avance en el desarrollo de software conjugado con una sociedad cada

vez ms tecnificada, lleva al profesional en Ingeniera de Sistemas a la
necesidad de conocer, dominar y aplicar las mejores prcticas para el
anlisis de las necesidades de informacin de las organizaciones y la
recopilacin de los requerimientos del software.

En el curso Ingeniera de Requerimientos se imparten los conocimientos

necesarios para aplicar nuevos mtodos, tcnicas y herramientas en la
gestin de los deseos, necesidades y expectativas de los clientes y
convertirlas en requerimientos funcionales y no funcionales, acordados con
los interesados involucrados y a ser satisfechos a travs de un sistema
informtico.

Las competencias generales de la carrera Ingeniera de Sistemas

que se desarrollan en el curso son:
- Diseo de sistemas y procesos. Habilidad para disear sistemas,
componentes o procesos en base a necesidades y considerando
restricciones econmicas, sociales, polticas, ticas, de salud, seguridad,
medio ambiente, de manufactura y sostenibilidad.
- Trabajo en equipo. Habilidad para formar equipos multidisciplinarios.
- Comunicacin. Habilidad para comunicarse eficientemente en forma oral,
escrita con informes o artefactos en sistemas de informacin.

5
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Logros de aprendizaje

Al trmino de la sesin, el estudiante construye el modelo de casos de usos del sistema

por paquetes.

6
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Encontrar los actores y casos de uso del sistema

Anlisis del modelo de casos de uso del negocio

Es importante llegar a este punto de la metodologa teniendo claridad del negocio, para
que este paso del modelado del negocio al modelado del sistema sea un proceso
consecuente.

Tal como se muestra en el diagrama a partir de los artefactos generados del anlisis del
modelo de casos de uso del negocio se genera los artefactos del modelo de casos de uso
del sistema.

Identificar actores del sistema

Para ello, en primer lugar, identificaremos cules son los actores del sistema.
Un actor del sistema (actor) representa un rol (humano, software o hardware) externo
al sistema con el que se establece intercambio directo de informacin.
Por ejemplo, vendedor, jefe de almacn o asistente de produccin.

Dnde encontrar a los actores del sistema?

Una vez que conocemos qu es un actor de sistema, cabe preguntarse: dnde
encontrar a los actores del sistema?
La respuesta a esta cuestin, est en los llamados trabajadores de negocio (bussiness
workers). De tal forma que, por cada trabajador de negocio con actividades a
automatizar se identifica a un actor del sistema, al cual se le da el mismo nombre que al
trabajador de negocio.

7
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Existen algunas excepciones cuando el rol del actor del negocio y el rol del trabajador
del negocio se pueden convertir en un actor del sistema.
Cundo sucede esto?
Si la primera actividad del trabajador del negocio es automatizable y es factible que lo
pueda realizar el actor del negocio, es cuando este rol pasa a juntarse en uno solo, al
definirse el actor del sistema.
Por ejemplo, como vemos en el diagrama:

En el modelado del negocio identificamos que el actor es el viajero que quiere comprar
un boleto de avin y se acerca a una agencia de viajes y solicita al agente de viajes
(trabajador de negocio), quien lo atiende y le ayuda a reservar y/o comprar su boleto de
viaje.
Al pasar al modelo del sistema identificamos que si automatizamos este proceso el
viajero podra tranquilamente asumir el rol del agente de viajes y hacer su reserva
directamente en el sistema, tal como lo propuso la empresa area LAN al poner su
pgina web de reservas y el cliente directamente compra su boleto sin necesidad del
agente de viajes.

8
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Entonces tenemos un ejemplo donde el actor del negocio y el trabajador de ese caso de
uso se convierten en un actor del sistema.

Otros elementos que ayudan a encontrar a los actores del sistema.

Personas que usan el sistema.
Personas que interactuarn con el sistema.
Personas que proveen informacin al sistema.
Usuarios que requieren ayuda de parte del sistema para poder desarrollar sus
actividades o tareas.
Usuarios que desarrollan funciones secundarias, tales como mantenimiento y
administracin del sistema.
Personas que instalarn el sistema.
Software o hardware externos a la frontera del sistema con los que el sistema
requiera interactuar.

Sugerencias para identificar adecuadamente a los actores del sistema.

Son roles (humanos, software o hardware), no personas con nombres propios.
No siempre est asociado con el nombre de un cargo en la planilla de la
organizacin objetivo.
El nombre no debe representar reas, departamentos o partes de una
organizacin sino roles de ejecucin.
Cada actor debe estar asociado con al menos un caso de uso del sistema.
o Si no participa en ningn proceso debe ser eliminado del modelo.

Ejemplo: Un actor representa varias instancias.

En el siguiente ejemplo se muestra el papel que ejercen Ivn y Toms en un banco.
Ambos son clientes y estn representados en el diagrama como el actor cliente. Es
decir, tenemos el caso de que ms de una persona desempea un mismo rol.

9
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Una persona representa el rol de varios actores

En este siguiente ejemplo se puede observar, que una persona puede desempear ms
de un rol de sistema, es decir de varios actores de sistema. Por ejemplo, Ivn tambin
es el operador del cajero y est representado en el diagrama como el actor operador,
cuando realiza sus labores en la empresa. Por lo tanto, vemos cmo desempea un
doble rol, el del actor operador que utiliza el sistema de informacin del cajero, y actor
cliente cuando tiene que retirar dinero del cajero.

Relacin entre actor del sistema, usuario y rol

Ahora, veamos la relacin entre actor del sistema, usuario y rol.
En el primer recuadro podemos observar como un usuario, en este caso Toms, juega
un rol (vendedor) y es representado por un actor del sistema.
En el segundo, varios usuario (Toms, Mara y Jos) juegan un rol (vendedor)
representados por un solo actor, el mismos en todos los casos.
En el ltimo recuadro un usuario juega varios roles (vendedor y jefe de estudios) y es
representado por un solo actor del sistema

10
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Por lo tanto, un usuario puede representar uno o varios roles, pero ese rol va a estar
representado por el mismo actor del sistema.

Identificar casos de uso de sistema

Una vez identificados los actores del sistema, nos centraremos ahora en identificar casos
de uso del sistema.
Para empezar, un caso de uso del sistema identifica:
Un proceso especfico del sistema con identidad propia.
Define una secuencia de acciones que el sistema realiza para un actor en
particular.
Produce un resultado observable y esperado para el actor correspondiente.

Dnde encontrar casos de uso del sistema?

Este interrogante nos lleva a plantearnos otros:
Cules son las actividades del negocio objetos de automatizacin?
Cules son las tareas que el actor desea que el sistema desarrolle?
El actor crea, almacena, cambia, elimina o consulta datos en el sistema?
El actor necesita informar al sistema cambios generados en el entorno
circundante al sistema?
El actor necesita ser informado sobre la ocurrencia de situaciones externas al
sistema?
Al responder a estas preguntas, podremos identificar los casos de uso de sistema,
pues estos dependen de las tareas que los actores de negocio necesitan que se
ejecuten y que implica la manipulacin de las entidades del negocio.

11
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Sugerencias de identificacin
A continuacin, les mostramos algunas sugerencias para identificar adecuadamente los
casos de uso del sistema.
Son proceso del sistema, que en muchos casos corresponden con opciones de
ejecucin.
Deben estar asociados a por lo menos un actor del sistema u otro caso de uso
del sistema.
Representan la generalidad del comportamiento del proceso y no una instancia
o escenario especfico o caso muy particular del sistema

Orientaciones de los casos de uso del sistema

Entonces, Los casos de uso del sistema deben ser identificados segn las operaciones
o tareas que se acuerden que el sistema debe realizar o segn los objetos que contengan
las operaciones o tareas que se acuerden para el sistema?
Respondiendo a esta pregunta, si los casos de uso del sistema estn orientados a
operaciones y tareas.
Ser necesario que el sistema permita al vendedor:
Agregar informacin de los clientes.
Modificar informacin de los clientes.
Y, consultar informacin de los clientes.
Y si representamos esas tareas en el modelo de casos de uso del sistema tendremos el
diagrama que se muestra.

12
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Si se cumple estas condiciones, los casos de uso de sistemas estarn orientados a las
tareas que realizan los objetos de tipo CLIENTE. Y, se identificarn teniendo en cuenta
cada operacin necesitada.
Por tanto hablamos del paradigma estructurado.

Para que la propuesta est orientada a objetivos, el sistema debe permitir al vendedor
actualizar la informacin de los clientes.
Representado el modelo de caso de uso del sistema de acuerdo al diagrama que se
muestra a continuacin.

De esta forma los casos de uso del sistema estarn orientados a los objetos cliente que
realizan las operaciones o tareas y, a su vez, se identificarn teniendo en cuenta el objeto
involucrado.

Repercusiones en la arquitectura del sistema

A su vez, hay que tener en cuenta las repercusiones en la arquitectura del sistema. Estas
pueden ser por:
Mantenibilidad
Modificabilidad
Escalabilidad
Portabilidad
Mantenibilidad
Capacidad del SW para ser reparado y mejorado de forma eficiente, de manera rpida y
a bajo costo.

13
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Modificabilidad
Capacidad del SW para ser sometido a cambios futuros.
Escalabilidad
Es el grado con el que se pueden ampliar la arquitectura de SW, de datos o los
requerimientos funcionales.
Portabilidad
Capacidad del SW para ser transferido de un entorno a otro, sea la organizacin,
hardware o software.
Para finalizar este apartado, conviene matizar algunos puntos.
Por una lado, los sistemas orientados a objetos permiten arquitecturas ms escalables,
modificables, mantenibles y portables que los estructurados u orientados a operaciones.
Adems, las arquitecturas orientadas a objetos se adaptan mejor a los cambios en las
necesidades y los requerimientos.
Por otro lado, en cuanto a la identificacin de los casos de uso del sistema, stos deben
ser identificados orientados a objetos para permitir arquitecturas de software y sistemas
ms escalables, modificables, mantenibles y portables.

Cmo afrontar cambios?

Si en el futuro, el negocio necesitara incluir una operacin nueva al vendedor sobre la
informacin de los clientes. Por ejemplo: Permitir al vendedor imprimir la informacin
de los clientes.

14
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Para poder afrontar cambios estructurados es necesario que el sistema permita al

vendedor
Agregar informacin de los clientes.
Modificar informacin de los clientes.
Consultar informacin de los clientes.
Imprimir informacin de los clientes.
De esta forma, la arquitectura deber cambiar para aceptar el nuevo requerimiento.

Cmo afrontar los cambios? Orientados al objetivo

En cuanto a cmo afrontar los cambios orientados al objeto, es necesario que el sistema
permita al vendedor actualizar la informacin del cliente. De esta forma, la arquitectura
del sistema no necesitar cambiar para aceptar el nuevo requerimiento.

Consideraciones
Si el negocio tiene reglas sobre alguna restriccin o imposicin.
Ejemplo: RN7. La eliminacin de los clientes solo la puede realizar el Jefe de los
Vendedores.
Tengamos en cuenta algunas consideraciones, en cuanto a los requerimientos
funcionales dentro del modelo de casos de usos del sistema:
Dado que la regla de negocio del ejemplo implica la funcionalidad de un nuevo rol,
esto implica separar las funcionalidades en un nuevo caso de uso para este nuevo rol.

15
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

En el modelo estructurado quedara:

Por un lado, el sistema debe permitir al vendedor:

Agregar informacin de los clientes.
Modificar informacin de los clientes.
Consultar informacin de los clientes.
Imprimir informacin de los clientes.
Y, por otro debe permitir al Jefe de Vendedores eliminar informacin de los clientes .

Sin embargo en el modelo orientado a objetos se tendran las siguientes

consideraciones:
Dado que se requiere que esta nueva funcionalidad lo asuma otro rol se hace necesario
modelar el nuevo caso de uso del sistema que estara asociado a este nuevo rol o actor
del sistema. Es decir el actor del sistema Jefe de Vendedores estara asociado al caso de
uso del sistema eliminar informacin de los clientes.
Por tanto, aunque se necesite dar atencin especfica a algunas operaciones, la
arquitectura sigue estando orientada a objetivos.

16
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Identificar los paquetes del sistema

Encontrar los diferentes mdulos del sistema

Para comenzar, vamos a intentar encontrar los diferentes mdulos del sistema.
Para ello es necesario dejar claro los que entendemos por paquete. Un paquete es una
coleccin de artefactos (casos de uso, actores, relaciones, diagramas y otros paquetes)
que se utiliza para dividir un modelo en partes de menor tamao.
Por ejemplo: Paquete Ventas, Paquete Seguridad
Siguiendo con la definicin de paquete. Un paquete hace ms fcil la definicin de la
arquitectura y facilita la asignacin de responsabilidades y tareas a los miembros del
equipo de proyectos
Por tanto, cundo utilizar paquetes dentro del Modelo de Casos de Uso del Sistema?
Se hace necesario el uso de paquetes de sistema, si el nmero de actores y casos de uso
es elevado.

Cmo definir los paquetes del sistema?

Otra pregunta que se nos plantea es: cmo definir los paquetes del sistema?
Por cada grupo de casos de uso del sistema.
o Los paquetes del sistema pueden ser manejados por un mismo actor.
o Pueden responder a una funcionalidad similar.
o Pueden ser definidos por complejidad de desarrollo.
Adems, los procesos del negocio (casos de uso del negocio) pueden ayudar a
identificar los paquetes.

17
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Identificar la dependencia entre los paquetes

Para ello, es esencial tener en cuenta que la asociacin entre los paquetes es de tipo
dependiente, lo que indica que los procesos de un paquete dependen de algunos o todos
los procesos de otros paquete.
En el ejemplo, se muestra como algunos o todos los procesos del PAQUETE 1 dependen
de algunos os todos los procesos del PAQUETE 2.

Adems, deben evitarse dependencias doble entre paquetes.

Si la dependencia entre los procesos de ambos paquetes es tan fuerte y combinada es

preferible:

Unir los dos paquetes en uno solo.

Reconsiderar nuevos paquetes con diferente distribucin de casos de uso del
sistema.

Diagrama de Paquete del sistema. Ejemplo

En los siguientes esquemas, se muestra como ejemplo un diagrama de paquetes del
sistema.

18
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Construir el Modelo de casos de uso del sistema

Para ello, tendremos que tener en cuenta que el

Modelo de casos de Uso est formado por:
Actores.
Asociaciones entre actores y casos de uso.
Diagrama de Actores.
Paquetes.
Dependencias entre paquetes.
Diagrama de Paquetes.
Casos de uso.
Asociaciones entre casos de uso.
El diagrama de Casos de Uso.

De todos ello, nos centraremos en explicar las

Asociaciones entre actores y casos de uso y los
Diagramas de Casos de Uso.

Asociaciones actores y casos de uso del sistema

Las asociaciones entre actores y casos de uso del sistema consisten en identificar qu
actores del sistema se benefician de cules casos de uso del negocio. Para ello, se define
una asociacin unidireccional entre ellos, a travs de una lnea continua.

19
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Diagrama de Casos de Uso del sistema

El diagrama de casos de uso del sistema es una herramienta proporcionada por UML
que muestra los procesos que son usados por los roles del sistema
En l solo se tiene en cuenta QUIN realiza QU proceso?, es decir:
QUIN? (actor del sistema identificado).
QU? (caso de uso del sistema identificado).
Las relaciones entre ellos (asociaciones).
Por ltimo, hay que tener en cuenta que no constituye un Diagrama de Flujo de Datos.

20
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Conclusiones
Como conclusiones se debe recalcar que:
La identificacin de los requerimientos funcionales llevar a la proyeccin de las
funciones del sistema.
La descripcin de los requerimientos no funcionales facilitarn la construccin
de la plataforma del sistema.
La construccin del Modelo de Casos de Uso del Sistema permitir la definicin
de la arquitectura del sistema.

21
Universidad Peruana de Ciencias Aplicadas
 Ingeniera de requerimientos

Bibliografa

BOOCH, Grady (1999) The unified modeling language: user

guide. Reading, MA : Addison-Wesley (005.117 BOOC/U)
Jacobson, Ivar (2000) El proceso unificado de desarrollo de software / 005.1068
JACO Madrid: Pearson Educacin, 2000.

BRUEGGE, Bernd (2002) Ingeniera de software orientado a

objetos. Mxico, D.F.: Pearson Educacin (005.117 BRUE)
IBM (2009)Rational Software 21 de abril de 2009 (http://www-
01.ibm.com/software/rational/)
OMG (2009) Sitio web de Object Management Group 21 de abril de
2009 (http://www.omg.org/)
PRESSMAN, Roger S. (2005) Ingeniera de software: un enfoque
prctico. Mxico, D.F. : McGraw-Hill

22
Universidad Peruana de Ciencias Aplicadas