ACTIVIDAD DE APRENDIZAJE 1

DIAGRAMAS DE CASOS DE USO, MODELAMIENTO DE OBJETOS

Y DIAGRAMAS UML DE CLASES EN POO

GIOVANNI FRANCISCO HERNANDEZ CASTILLO

FUNDACION UNIVERSITARIA PANAMERICANA

TÉCNICO EN ANALISIS Y DISEÑO DE BASES DE DATOS
BOGOTÁ
2015
 ACTIVIDAD DE APRENDIZAJE 1

CASOS DE USO, MODELAMIENTO DE OBJETOS

Y DIAGRAMAS UML EN POO

GIOVANNI FRANCISCO HERNANDEZ CASTILLO

EDGAR MAURICIO RUIZ OSUNA

(Tutor Virtual)

FUNDACION UNIVERSITARIA PANAMERICANA

TÉCNICO EN ANALISIS Y DISEÑO DE BASES DE DATOS
BOGOTÁ
2015
 CONTENIDO

PLANTEAMIENTO DEL PROBLEMA………………………………………………….

1 TABLA EXPLICATIVA DE REQUISITOS DEL PROBLEMA COMO CASOS DE
USO (ESCENARIO NORMAL – ESCENARIO CON PROBLEMAS)……………….
2 DESARROLLO DEL MODELO DE OBJETOS
2.1 IDENTIFICACION DE OBJETOS Y
CLASES....................................................................................................................

2.2 IDENTIFICAR Y DEPURAR RELACIONES

CONCLUSIONES.....................................................................................................

2.3 IDENTIFICAR ATRIBUTOS DE OBJETOS Y

RELACIONES….......................................................................................................

3 DIAGRAMAS UML Y DE CLASE..........................................................................

BIBLIOGRAFIA……………………………………………………………………………
 PLANTEAMIENTO DEL PROBLEMA

Se desea diseñar el software necesario para una red bancaria provista de cajeros
automáticos (ATM, automatic teller machines) que serán compartidos por un
consorcio de bancos. Para la primera etapa del proyecto se diseñará el programa
para los cajeros automáticos utilizando programación orientada a objetos.

Los cajeros automáticos aceptan tarjetas de crédito, interaccionan con el usuario,

se comunican con un computador central para llevar a cabo las transacciones,
entregan dinero en efectivo al usuario e imprimen recibos. El sistema llevará
correctamente el registro de las transacciones efectuadas, cumplirá características
aceptables de seguridad y manejará correctamente accesos concurrentes a la
misma cuenta.

El jefe de programación le solicita un informe escrito con las siguientes

características:

1. Tabla explicativa donde se expresen los requisitos del problema como Casos de
Uso (Escenario Normal- Escenario con Problemas).

2. Desarrollo de modelamiento de objetos, que consta de los siguientes pasos:

 Identificar objetos y clases

 Identificar y depurar relaciones
 Identificar atributos de objetos y relaciones

3. diagramas UML y de clase basados en el modelamiento de objetos.

1 TABLA EXPLICATIVA REQUISITOS DEL PROBLEMA
DIAGRAMA GENERAL DE LOS DIFERENTES CASOS DE USO
Extensión «extend»

Es una forma de interacción, un caso de uso dado (la extensión) puede extender a
otro. Esta relación indica que el comportamiento del caso de la extensión se utiliza
en casos de uso. El caso de uso extensión puede ser insertado en el caso de uso
extendido bajo ciertas condiciones. Para el ejemplo del cajero, el caso de uso
retirar dinero es muy similar a hacer una transferencia, solo tiene ciertas
variaciones, por tanto hay un conjunto de casos de uso para realizar una
operación en un cajero.

Inclusión « include » o use

Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro
caso de uso. El primer caso de uso a menudo depende del resultado del caso de
uso incluido. Si el actor realiza el caso de uso base tendrá que realizar también el
caso de uso incluido. En el ejemplo del cajero automatico no podemos realizar
operación sin validar tarjeta y clave.
 2 DESARROLLO DEL MODELO DE OBJETOS

2.1 IDENTIFICAR OBJETOS Y CLASES

Seleccionamos nombres en los requisitos candidatos a ser objetos y clases:

Se desea diseñar el software necesario para una red bancaria provista de

cajeros automáticos o ATM (automatic teller machines) que serán compartidos
por un consorcio de bancos. Para la primera etapa del proyecto se diseñará el
programa para los cajeros automáticos utilizando programación orientada a
objetos.

Los cajeros automáticos aceptan tarjetas de crédito, interaccionan con el usuario,

se comunican con un computador central para llevar a cabo las transacciones,
entregan dinero en efectivo al usuario e imprimen recibos. El sistema llevará
correctamente el registro de las transacciones efectuadas, cumplirá
características aceptables de seguridad y manejará correctamente accesos
concurrentes a la misma cuenta.

Lista de nombres:

Software Tarjeta de crédito

Red bancaria Usuario

Cajero automático Ordenador Central

Consorcio de bancos Transacción remota

Banco Dinero en efectivo

Servidores Recibo

Cuenta bancaria Sistema

Información cuenta Registro de transacciones

Transacción de cajero Características de seguridad

Estaciones de cajero Acceso a la cuenta

2.2 IDENTIFICAR Y DEPURAR RELACIONES

Eliminamos redundancias:

Cliente y usuario son la misma clase. Dejamos cliente por adaptarse mejor al
concepto.

Eliminamos clases vagas:

Sistema, características de seguridad y red bancaria.

2.3 IDENTIFICAR ATRIBUTOS DE OBJETOS Y RELACIONES

Los atributos definen datos asociados a un objeto. Un atributo objeto se

representa mediante una relación. En este ejemplo pueden considerarse objetos:

 Dinero en efectivo
 Recibo o tirilla
 Información sobre la cuenta

Eliminar objetos de diseño:

Registro de transacciones, acceso a la cuenta y Software

 Cajero Automático
 Consorcio de bancos
 Banco
 Servidores
 Cuenta bancaria
 Transacción
 Estaciones de cajero
 Cajero humano
 Tarjeta de crédito
 Computador central
 Cliente

Seleccionamos verbos relacionales en los requisitos:

 Una Red bancaria tiene Cajeros automáticos.

 El Consorcio de bancos comparte los Cajeros automáticos.
 Cada Banco tiene un Servidor.
 El Servidor dispone de Software.
 Cada Servidor lleva la información sobre las Cuentas bancarias.
 Cada Servidor procesa Transacciones.
 Una Transacción actúa sobre una Cuenta bancaria.
 Las Estaciones de cajero están conectadas al Servidor.
 Las Estaciones de cajero son del Banco.
 El Cajero humano opera en la Estación de cajero.
 El Cajero humano crea Cuentas bancarias.
 El Cajero humano introduce Transacciones sobre las Cuentas bancarias.
 Los Cajeros automáticos aceptan Tarjetas de crédito.
  Los Cajeros interaccionan con el Usuario
 Los Cajeros automáticos comunican con el ordenador central.
 El Ordenador central lleva las Transacciones.
 Los Cajeros automáticos entregan Dinero en efectivo al Usuario.
 Los Cajeros automáticos imprimen Recibos.
 El Sistema lleva el Registro de las transacciones.
 El Sistema cumple Características de seguridad.
 El Sistema maneja Accesos concurrentes a la Cuenta bancaria.
 Los Bancos forman parte del Consorcio.
 Los Clientes del banco tienen Tarjetas de crédito.

Relaciones adicionales

 Las Cuentas bancarias están en los Bancos.

 El computador central pertenece al Consorcio.
 Los Bancos tienen Clientes.

Eliminamos las relaciones de diseño:

 Una Red bancaria está provista de Cajeros automáticos.

 El Servidor dispone de Software.
 Los Cajeros automáticos entregan Dinero en efectivo al Usuario.
 Los Cajeros automáticos imprimen Recibos.
 El Sistema lleva el Registro de las transacciones.
 El Sistema cumple Características de seguridad.
 El Sistema maneja Accesos concurrentes a la Cuenta bancaria.
 El Coste de desarrollo se divide entre los Bancos.

Eliminamos eventos transitorios:

 Los Cajeros automáticos aceptan Tarjetas de crédito.

 Los Cajeros interaccionan con el Usuario

El Ordenador central lleva a cabo las Transacciones, se cambia por:

 El Ordenador central lleva se comunica con el banco.

El Cajero humano introduce Transacciones sobre las Cuentas bancarias, se

descompone en 2 relaciones binarias:

 el cajero humano introduce transacciones y,

 las transacciones actúan sobre las cuentas bancarias.

Se añaden relaciones que no aparecen a simple vista:

  Los clientes tienen cuentas
 Las transacciones son autorizadas por la tarjeta de crédito
 Las transacciones pueden introducirse en una estación de cajero

Se define la multiplicidad de asociación:

 Un Banco puede tener muchas Cuentas

 Un Cliente puede tener muchas Cuentas
 Un Cliente puede tener muchas Tarjetas de crédito
 Un Banco emplea muchos Cajeros
 Un Banco tiene un solo Ordenador del banco
 El Computador central se comunica con muchos computadores del banco

Atributos de los objetos

Del Banco: Nombre

De la Cuenta: Saldo, Límite de crédito, Tipo de cuenta

Del Cliente: Nombre, Dirección

Del Cajero: Nombre

De una Transacción del cajero: Tipo, Fecha y hora, Cantidad

Del Cajero automático: Efectivo disponible, Cantidad entregada

De una Transacción remota: Tipo, Fecha y hora, Cantidad

De la Tarjeta de crédito: Clave, Código de la tarjeta

Atributos de las relaciones

La multiplicidad de la relación queda sobreentendida al usar un código

Código de la estación de cajero

Código del cajero automático

Código del banco

Código del banco

Código de la cuenta

Código de empleado
3 DIAGRAMA DE CLASES Y ATRIBUTOS

Para la creación del diagrama de este ejemplo se utilizó la herramienta ArgoUML

 BIBLIOGRAFÍA

- http://www.astreo.ii.uam.es/~jlara/TACCII/5.1_Ejemplos_UML.pdf .
- http://www.kybele.etsii.urjc.es/docencia/IS3/2012-2013/Material/Ejemplo
%20Completo%20Cajero%20Autom%C3%A1tico.pdf