MODELAMIENTO CASOS DE USO

PRESENTADO A:
JULIO BARON VELANDIA.

PRESENTADO POR:

Daniel David Leal Lara

20151020057
Brayan Leonardo Sierra Forero
20151020059
Jairo Andres Romero Triana
201510200

PREGRADO EN INGENIERÍA DE SISTEMAS

FUNDAMENTOS DE INGENIERÍA DE SOFTWARE
GRUPO 020 - 81
BOGOTÁ
2018

1
Tabla de contenido
Tabla de contenido 2
Introducción 3
Objetivos 4
Desarrollo 5
1- Planteamiento del escenario 5
2- Selección de los casos de uso 6
3- Diagramas de casos de uso. 7
4 - Diagrama De Clases 10
5- Diagramas De Secuencia 13
Diagrama de secuencia (consultar Saldo) 13
Diagrama de secuencia (Retirar Dinero) 13
Diagrama De Secuencia (Cuenta Nueva) 14
6- Diagrama de Estado 15
7- Implementación Java 16
8- Pruebas Unitarias 19
Conclusiones 21
Bibliografía 22
Recursos Electrónicos 22

2
Introducción
Para elaborar un determinado proyecto, es importante tener como guía un modelo o
metodología que permita establecer las pautas a seguir para cubrir las necesidades que
pueda llegar a tener este proyecto. Entre estas pautas se encuentra la obtención de
requerimientos lo cual marca un punto importante y primordial en la iniciación de un proyecto
dado que una mala obtención o entendimiento de estos, puede producir en fases más
profundas errores que podrían retrasar o incluso destruir cualquier proyecto.
Para la obtención adecuada de requerimientos existen los casos de uso los cuales
proporcionan una descripción muy precisa de lo que requiere el cliente, además refleja
algunos procesos importantes que se deben tener en cuenta en la realización del proyecto
junto con la definición de los actores que participaran en el mismo de una u otra forma.
Una vez se tienen planteados adecuadamente los casos de uso, se puede realizar el diseño
del software lo cual se ve representado en diagramas de diferentes tipos como diagramas de
clase, diagramas de secuencia o diagramas de estado entre otros, esto brinda un mapa o una
guía que proporciona facilidad y cierto tipo de fluidez a la hora de plasmar las ideas y
requerimientos en código fuente.
Cuando se realiza la elaboración del código fuente en un proyecto de software, es vital,
planear algunas pruebas antes de empezar a desarrollar código, estas pruebas pueden ser
planteadas incluso desde el diseño de la aplicación que es lo más recomendable, de esta
forma y junto con los diagramas elaborados en el diseño, se pueden evitar grandes
complicaciones y tener un control constante de lo que se está produciendo.
En el presente documento, se realizarán diferentes casos de uso para algunos requerimientos
obtenidos de un sistema bancario, estos serán representados posteriormente en diagramas
de secuencia, en un diagrama de estado y un diagrama de clases junto con la planeación de
algunas pruebas a realizar, y por último se plasmarán estos diseños en código fuente.

3
Objetivos
● Identificar e implementar los diferentes casos de uso presentes para un sistema
bancario a fin de atender las posibles solicitudes que se tengan.
● Realizar un diagrama de clases que represente lo planteado en los casos de
uso junto con la planeación de algunas pruebas unitarias, esto a fin de lograr
establecer un mapa a seguir entendible y funcional para la implementación del
código fuente del proyecto.
● Establecer los diferentes diagramas de secuencia de acuerdo a los casos de
uso planteados anteriormente a fin de encontrar métodos no previstos en un
inicio y entender de mejor forma los procesos que se llevarán a cabo en fases
posteriores.
● Construir un diagrama de estado que permita representar el comportamiento
en diferentes etapas de los casos de uso descritos y así lograr una visión más
clara de cómo actuaran estos en una implementación posterior en código
fuente.
● Implementar el desarrollo en código fuente del diagrama de clases planteado,
esto a fin de establecer en físico las funcionalidades pensadas en un principio
con los casos de uso y los demás diagramas elaborados.
● Mediante la elaboración y modelamiento de los casos de uso en forma de
diagramas junto con el desarrollo en código fuente del mismo, afianzar los
conocimientos adquiridos previamente y conseguir nuevas competencias
favorables para el desarrollo integral en la ingeniería de sistemas.

4
Desarrollo

1- Planteamiento del escenario

El escenario planteado por el docente en una de las sesiones de la clase fue el de un banco.
Para este, se debe cumplir con los requisitos mínimos de un banco ante sus clientes, los
cuales son:
● Inscribir C.A
● Realizar Consignación
● Retirar Dinero
● Consultar Saldo
● Solicitar Certificación C.A
● Realizar Donación

5
 2- Selección de los casos de uso

En primer lugar se plantea el diagrama de los casos de uso con la herramienta de diseño
UML; en este se representa el actor principal “Cliente” y los diferentes servicios que puede
solicitar a un sistema bancario.

Seguidamente, se elabora la matriz de casos de uso que permite identificar cuáles son de
mayor importancia en comparación con los demás.

C1 C2 C3 C4 C5 C6

Inscribir C.A X X X X X
(C1)

Realizar
Consignación
(C2)

Retirar Dinero X X
(C3)

Consultar X X
Saldo (C4)

Solicitar

6
Certificación
C.A (C5)

Realizar
Donación (C7)

De la matriz anterior de casos de uso se aprecian las diferentes soluciones que más influencia
dan a nuestro escenario, estas son:
- Inscripción C.A
- Retirar Dinero
- Consultar Saldo

3- Diagramas de casos de uso.

- Consultar saldo: Este escenario se presenta cuando un cliente se acerca a alguno
de los cajeros del banco con el fin de conocer el saldo que tiene disponible. El proceso
inicia cuando el cliente le pide al sistema una consulta de saldo, a lo cual el sistema le
solicita una serie de datos asociados a su seguridad personal para su posterior
validación, el cliente ingresa sus respectivos datos y el sistema por medio de la cuenta
valida sus datos y le da una respuesta.
- Retirar dinero: Este escenario se da cuando un cliente se acerca a alguno de los
cajeros disponibles asociados al banco con el fin de retirar cierta cantidad de dinero
de su cuenta bancaria. El proceso inicia cuando el cliente realiza una solicitud al cajero
electrónico para retirar dinero, a lo cual, el cajero electrónico responde con la solicitud
de una serie de datos asociados a su seguridad personal para validar la cuenta,
adicional, le pide el monto a retirar, el cajero valida la información registrada con la
información existente en la cuenta y devuelve en pantalla el valor restante junto con el
dinero en físico retirado.
- Cuenta nueva: Este escenario resulta cuando un cliente se acerca a alguna de las
oficinas con el fin de abrir una nueva cuenta en el banco, el cliente ingresa sus
respectivos datos al sistema y el sistema bancario se le asigna a un asesor para
atender la petición del cliente, este analiza su información y devuelve el resultado de
la petición al cliente.

ID Caso de uso : C4

Nombre: Consultar saldo

Resumen
Caso de Uso Actores: Cliente

Descripción Se presenta cuando el cliente desea

conocer la cantidad de dinero disponible
en su cuenta asociada al banco

Precondición: - Tener cuenta bancaria creada y

Caso de Uso asociada al banco
- Disponer de número de cuenta y

7
 Formato contraseña
Extendido
Actor/es Sistema

- 1 Solicitud de - 1.1 Solicitud de

consulta de saldo número de cuenta y
contraseña
- 1.2 Ingresa datos
(Num de cuenta y - 1.3 Valida la
Contraseña) información
- 1.4 Realiza consulta
en su base de datos
con número de
cuenta asociado
- 1.5 Retorna
- 1.6 Recibe información asociada
información al saldo de la cuenta
solicitada

Postcondicion - Registrar consulta en historial

es: - Notificar consulta (Correo)

ID Caso de uso : C3

Nombre: Retirar Dinero

Resumen
Caso de Uso Actores: Cliente

Descripción Se presenta cuando el cliente desea

realizar un retiro (descuento) de su cuenta.

Precondición: - Tener cuenta bancaria creada y

asociada al banco
- Disponer de número de cuenta y
Caso de Uso
contraseña
Formato
- Tener fondos disponibles en la
Extendido
cuenta y suficientes para retirar

Actor/es Sistema

- 1 El cliente solicita - 1.1 Valida

realizar un retiro, información de la
facilita la tarjeta y da tarjeta y solicita
un monto a retirar Usuario y contraseña

- 1.2 Ingresa datos - 1.3 Valida la

(Num de cuenta y información
Contraseña) - 1.4 Realiza consulta
en su base de datos

8
 con número de
cuenta asociado
-

Postcondicion - Registrar retiro en historial

es: - Actualizar valor del monto total
- Notificar transacción (Email)

ID Caso de uso : C1

Nombre: Inscribir C.A

Resumen
Caso de Uso Actores: Representante banco, Solicitante

Descripción Se presenta cuando una persona

desea abrir una cuenta en el banco.

Precondición: - Mayor 12 años

- Num ID persona
Caso de Uso Actor/es Sistema
Formato
Extendido
- 1. Solicitud apertura
de cuenta. - 1.1 Solicita datos del
(Solicitante) cliente

- 1.2 Otorga
información - 1.3 Valida
(Nombre, apellido, información
fecha de nacimiento, - 1.4 Presenta
número de ID) resultado
(Solicitante) - 1.5 Pide aprobación

-1.6 Aprueba
(Representante banco)
- 1.7 Asigna ID cuenta
y contraseña.

Postcondiciones: Notificar datos cuenta

9
4 - Diagrama De Clases
A partir del análisis de los diferentes casos de uso descritos anteriormente, se identificaron
un total de siete clases relacionadas entre sí, necesarias para la realización del código fuente.
estas son:
1. SistemaBancario: Es una clase abstracta de la cual heredan tres clases concretas
que implementan todos sus métodos descritos, además, tiene asociadas dos clases
que se componen de ella “RepresentanteBancario e Historial”, tiene la clase “Cuenta”
que realiza un proceso de agregación y la clase persona que realiza una asociación
con esta.
2. Cuenta: Es una clase que tiene un proceso de auto utilización debido al uso de uno
de sus métodos “validación”, además tiene un proceso de agregación con la clase
“SistemaBancario” y es usada por la clase “Persona”.
3. Persona: Esta clase se asocia con la clase “Cuenta” dado que necesita sus atributos,
además se asocia con la clase “SistemaBancario” para tener acceso a las clases
“Consulta”, “Retiro” y “CuentaNueva”, y así obtener los servicios que estas
proporcionan.
4. RepresentanteBancario: Esta es una clase que se compone de la clase
“SistemaBancario”, es decir que existe una dependencia fuerte, pues sin esta no
podría existir, además tiene una relación de asociación con sigo misma dado que
utiliza un método propio.
5. Historial: Al igual que “RepresentanteBancario”, esta clase tiene una dependencia
fuerte con la clase “SistemaBancario”, si desapareciese, esta también desaparecería,
pues es una extensión con una relación de composición.
6. Consulta: Esta es una clase concreta la cual hereda de la clase “SistemaBancario”,
esta le brinda ciertos métodos y le proporciona un puente para establecer contacto
con las diferentes clases relacionadas a esta.
7. Retiró: Esta, al igual que sus hermanas “Consulta” y “CuentaNueva”, es una clase
concreta la cual hereda de la clase “SistemaBancario”, esta clase superior le brinda
las conexiones necesarias para hacer contacto con las diferentes clases relacionadas.
8. CuentaNueva: Esta es una clase concreta o clase hijo, la cual hereda de su padre
“SistemaBancario” todos los métodos que necesita para brindar el servicio de crear
una nueva cuenta y asociarla a una persona, por medio de esta se implementa la
relación entre las clases “Cuenta” y “Persona”.

A continuación se muestra la implementación del diseño del diagrama de clases, tanto en su

modelo general, como en su modelo con pruebas unitarias.

Modelo Genérico

10
11
Modelo Con Pruebas Unitarias

12
5- Diagramas De Secuencia
Se realizaron un total de tres diagramas de secuencia en los cuales se describe la forma en
que se llevan a cabo los casos de uso (procedimiento), a continuación se describe brevemente
cada uno de estos.

Diagrama de secuencia (consultar Saldo)

Para el caso de uso “consultar saldo”, se tiene un actor en concreto “Persona” y el sistema
principal “SistemaBancario” con quien interactúa, además se tienen dos subsistemas
“Cuenta” e “Historial”, en los cuales se soporta el sistema principal para realizar validaciones,
consultas y registros, tal como se muestra a continuación.

Diagrama de secuencia (Retirar Dinero)

En este diagrama se representa el caso de uso “Retirar Dinero”, en este solo se involucra un
actor “persona” el cual interactúa directamente con el sistema “sistemaBancario” y este utiliza
dos subsistemas “Cuenta” e “Historial” para realizar procesos de validación, actualización de
información y registro de datos, tal como se muestra a continuación.

13
 Diagrama De Secuencia (Cuenta Nueva)

En este diagrama de secuencia, se representa el proceso de crear una nueva cuenta para un
cliente, en total, interactúan dos actores “Persona” y “ReprecentanteBancario” a través del
sistema global “SistemaBancario” para realizar la validación de los datos introducidos por el
primer actor, además, el sistema global utiliza un subsistema “Cuenta” para realizar el proceso
de asignación de cuenta, tal como se muestra a continuación.

14
6- Diagrama de Estado
Se realizó un diagrama de estado en donde se representaron los tres casos de uso escogidos
y descritos anteriormente. En este, resultaron cuatro estados principales, uno para cada caso
de uso y uno global para el funcionamiento de todo el sistema, además, se representan todos
los procesos que se llevan a cabo en cada caso de uso a modo de entrada y salida, siempre
retornando con una notificación al inicio del proceso en el estado global del sistema.

15
7- Implementación Del Código Fuente
A continuación, se dará un breve resumen de los factores más importantes de la respectiva
implementación del banco en java

Clases Usadas:

En la imagen anteriormente mostrada, se observan las diferentes clases usadas, nuestro main
el cual es el menú, el Sistema Bancario que es una clase abstracta y demás clases.

Se dará un breve seguimiento a consultar saldo.

16
La clase principal es el menú la cual da inicio al programa, en la misma se plantea que al
iniciar la ejecución, lo primero que debe hacer quien utiliza el programa es registrar sus datos
para así, lograr asociarlo a una cuenta nueva. Una vez creada la cuenta .se habilitan las
opciones de consultar saldo o retirar dinero del banco.

Se seguirá la petición de consultar saldo.

Consultar saldo corresponde al caso de digitar “1” en el menú, lo cual crea una nueva consulta
y le pasa como parámetro la cuenta asociada a la persona que se creó anteriormente, con
esto, se puede invocar el método solicitud datos de persona

17
En la imagen anterior se ve el método solicitudDatos de la clase Persona, la cual pide los
datos del usuario para proceder a compararlos con los datos creados por el Sistema y así,
guardarlos en la cuenta.

La siguiente imagen se relacionada con el método “ingresarDatos” de la aplicación que

corresponde al método “ingresarDatos” de la clase “Consulta”, esta hereda del sistema
bancario.

En la imagen anterior, se observa la creación de una solicitud la cual es un método para crear
el Id de solicitud, posteriormente, si el resultado de la solicitud para validar la cuenta es
correcta entonces pasará a dar la información de la solicitud y crear un nuevo historial
asociado al id de la solicitud.

En las imagen anteriores, se muestran dos métodos correspondientes a la clase cuenta, estos
se encargan de procesar y validar la información de “usuario” y “contraseña” digitada por el
cliente, comparándolo con los datos que tiene el programa, si son correctos entonces pasará
a notificar el saldo en (InformacionDeSolicitud()) y seguidamente a crear el historial como se
observa en la siguiente imagen,

Y termina el proceso de consulta de saldo.

18
(Imagen de la clase Abstracta Sistema Bancario)

8- Pruebas Unitarias
Se realizaron un total de tres pruebas unitarias, para lo cual fue necesario la utilización de
JUnit, estas pruebas fueron enfocadas en ciertos puntos cruciales del software desarrollado,
estas pruebas se describen a continuación:

1. Test Validar Registro en Historial

Esta es una prueba implementada con el fin de validar si la fecha creada por el método
“registro” de la clase “Historial”, corresponde efectivamente a la fecha actual del
sistema.

19
2. Test Validar Cuenta
Esta prueba fue implementada para verificar que se cree correctamente una cuenta
bancaria al pasarle atributos de nombre, apellido y fecha de nacimiento. Si los datos
son válidos se espera el booleano "True".

3. Test Validar Monto Existente

Esta prueba es implementada con el fin de verificar si el sistema valida correctamente
el “usuario”, la “contraseña” y el “saldo” con el saldo ya previamente establecido al
momento de crear la cuenta, por lo cual, en la prueba se espera un valor “False” dado
que se conoce de ante mano que el nombre del usuario es diferente al que se ingresa.

20
Conclusiones
● A partir de los casos de uso realizados, con un alto nivel de análisis y elaboración de
los mismos, se obtuvo una descripción general del sistema la cual permitió la
comprensión inicial de este y posteriormente, en base a este se logró desarrollar un
diagrama de clases que sirvió como guía para la elaboración del código fuente.
● Los diferentes diagramas trabajados a partir de los casos de uso, se pueden elaborar
de manera paralela o secuencial, o simplemente especializarse en uno de estos, pues
en ocasiones es más útil empezar por los diagramas de secuencia que centrarse
directamente en el diagrama de clases o de estados y viceversa, en otras situaciones,
solo se necesitan cierto tipo de diagramas, por lo tanto no sería necesario realizar los
demás, todo depende de cual sea el caso.
● La elaboración de los casos de uso, los diagramas de secuencia, el diagrama de
estados y el modelado de clases, facilitan de manera significativa abordar la
codificación del software, puesto que estos artefactos dan un punto de partida y una
ruta a seguir, además de proporcionar un foco constante en todo el desarrollo del
mismo..
● StarUML es una herramienta que agiliza toda la tarea del modelado de clases y los
diagramas de secuencia, puesto que podemos desarrollar ambos en un solo entorno,
nos permite trabajarlos de forma paralela y además nos brinda todas las utilidades
necesarias para la estructuración de estos.
● Mediante una temprana planeación o diseño de pruebas, se facilita en gran medida la
minimización de posibles errores que se puedan producir a lo largo del desarrollo del
código fuente, mediante estas, se puede obtener un control constante de lo que se
está elaborando.
● Mantener una concordancia en cuanto a lo que se diseña y lo que se desarrolla, es
vital para lograr obtener un producto de software confiable y consistente, puesto que
de otra forma, no serviría de nada o sería una pérdida de tiempo diseñar modelos o
diagramas que no se seguirán para hacer el código fuente y quedando así, en riesgo
de cometer errores catastróficos que pueden parar por completo el proyecto o
desviarse fácilmente de lo que se concibió en los casos de uso.

21
Bibliografía
● Relaciones entre clases: Diagramas de clases UML - Fernando Berzal
http://elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf

Recursos Electrónicos
● Tutoriales StarUML 2.8 (Videos), Recurso electrónico disponible en:
https://www.youtube.com/playlist?list=PLPM5lchG9xUvHP4ZVwEyiv9IzE8X3DkjFT
● Diagramas de secuencia UML, Recurso electrónico disponible en:
https://msdn.microsoft.com/es-co/library/dd409377.aspx

22