Universidad Nacional Abierta y a

Distancia de Mxico
Actividad 2. Importancia de las metodologas OMT y OOSE en el
diseo de sistemas orientados a objetos
Materia: Anlisis

y diseo orientado a objetos

Facilitador: JEANETTE CORINA CASTAEDA CORRAL

Fecha: 27/03/2015

Caso 1 metodologa Omt

Sistema de cajero automtico: ATM (Automated Teller Machine)

Disear el software para dar soporte a una red bancaria automatizada, que incluya tanto cajeros humanos
como cajeros automticos (CA), y que debern ser compartidos por un consorcio de bancos. Cada banco
proporciona sus propias computadoras para mantener sus cuentas y procesar transacciones relativas a ellas.
Las terminales de cajero son propiedades de cada banco, y se comunican directamente con las computadoras
del banco. Los cajeros humanos insertan los datos de la cuenta y de la transaccin. Los cajeros automticos
se comunican con una computadora central que aprueba las transacciones con los bancos adecuados. Los
cajeros automticos admiten tarjetas, interaccionan con el usuario, se comunican con el sistema central para
llevar a cabo la transaccin, entregan dinero e imprimen recibos. El sistema necesita mantener unos registros
adecuados y tambin las oportunas medidas de seguridad y debe admitir accesos concurrentes a una misma
cuenta de forma correcta. Los bancos proporcionarn su propio software para sus computadoras; el analista
debe disear el software para los CA y para la red. El coste del sistema compartido ser subsidiado entre los
bancos de acuerdo con el nmero de clientes que tengan sus tarjetas de crdito.

Diccionario de datos
Diccionario de datos para las clases de CA.
Identificar asociaciones entre objetos
Locuciones Verbales
La red bancaria incluye cajeros y CA
El consorcio comparte los CA.
El banco proporciona la computadora del banco.
La computadora del banco proporciona las cuentas.
La computadora del banco procesa las transacciones de cada cuenta.
El banco posee el punto de caja.
El punto de caja se comunica con la computadora del banco.
El cajero introduce las transacciones para la cuenta.
Los CA se comunican con la computadora central para la transaccin.
La computadora central verifica la transaccin con el banco.
El CA admite tarjetas bancarias.
El CA interacciona con el usuario.
El CA proporciona dinero.
El CA imprime recibos.
El sistema gestiona accesos concurrentes.
Los bancos aportan su software.
Los costes se subsidian entre los bancos.
Locuciones verbales implcitas

El consorcio est formado por bancos.

Los bancos tienen cuentas.
El consorcio posee la computadora central.
El sistema se encarga del registro.
El sistema se encarga de la seguridad.
Los clientes tienen tarjeta de crdito.
Conocimiento del dominio del problema
Las tarjetas de crdito acceden a cuentas.
Los bancos emplean cajeros.
Organizar y simplificar la clase de objetos usando herencia.

Modelo de objetos de un CA con atributos y herencia

Verificar que existen las vas de acceso adecuadas para las probables
consultas.
Iterar y refinar el modelo.

Agregar las clases en mdulos

MODELADO DINMICO:
Se preparan escenarios de secuencias tpicas de interaccin.
El CA pide al usuario que inserte una tarjeta; el usuario inserta una tarjeta de crdito.
El CA admite la tarjeta y lee su nmero de serie.
El CA solicita la contrasea; el usuario escribe "1234".
El CA verifica el nmero de serie y la contrasea con el consorcio; esta la comprueba con el banco "39" y
notifica la aceptacin al CA.
El CA pide al usuario que seleccione la clase de transaccin que desea (retirar fondos, hacer un ingreso o una
transferencia); el usuario selecciona retirar fondos.
El CA verifica que la cantidad se encuentre dentro de los lmites de crdito predefinidos, y pide al consorcio
que procese la transaccin; ste pasa la solicitud al banco, que eventualmente confirma el xito de la misma y
proporciona el nuevo saldo disponible en cuenta.
El CA proporciona el dinero y pide al usuario que lo recoja; ste toma el dinero.
El CA pregunta si el usuario desea continuar; ste dice que no.
El CA imprime un recibo, expulsa la tarjeta y pide al usuario que la recoja; el usuario toma el recibo y la tarjeta.
El CA pide a un usuario que inserte una tarjeta.
Escenario normal de un CA.
El CA pide al usuario que inserte una tarjeta; inserta una tarjeta de crdito.
El CA admite la tarjeta y se lee un nmero de serie.
El CA solicita la contrasea; el usuario escribe "9999".
El CA verifica el nmero de serie y la contrasea con el consorcio, que los rechaza despus de consultar con
el banco adecuado.
El CA indica que la contrasea es incorrecta, y pide al usuario que vuelva a escribirla; ste usuario escribe
"1234", y la tarjeta es admitida por el consorcio tras verificar el CA.
El CA pide al usuario que seleccione la clase de transaccin que desea; el usuario selecciona una retirada de
fondos.
El CA pregunta la cantidad de dinero; el usuario cambia de opinin y pulsa "cancelar".
El CA expulsa la tarjeta y pide al usuario la recoja, el usuario la recoge.
El CA pide a un usuario que inserte una tarjeta.

Un escenario de CA con excepciones.

Se identificar sucesos que acten entre objetos.
Formato de la interfaz ATM
Se prepara un seguimiento de sucesos para cada escenario.
Seguimiento de sucesos para un escenario de CA.
Diagrama de flujo de sucesos para el ejemplo de CA.
Se construye un diagrama de estados.
Diagrama de estados para la clase CA
Diagrama de estados para la clase Consorcio.
Diagrama de estados para la clase Banco.
Se comparan los sucesos intercambiados entre objetos para verificar la congruencia.
MODELO FUNCIONAL:
Identificar los valores de entrada y salida.
Valores de entrada y salida para el sistema CA.
Construir diagramas de flujo de datos que muestren las dependencias funcionales.
Diagrama de flujo de datos del ms alto nivel para el CA
Diagrama de flujo de datos para el proceso efectuar transaccin en un CA.
Describir funciones.
Actualizar cuenta (cuenta, cantidad, tipo-de-transaccin) -> dinero, recibo, mensaje
Si la cantidad que se intenta retirar supera el saldo disponible,
Rechazar la transaccin y no entregar ningn dinero.
Si la cantidad que se intenta retirar no supera el saldo disponible,
Cargar el importe y dispensar el efectivo solicitado
Si la transaccin es un ingreso,
Abandonar el importe y no dispensar efectivo.
Si la transaccin es una peticin de saldo
No dispensar efectivo.
En todo caso,
El recibo muestra el nmero del CA, fecha, hora, nmero de cuenta, tipo-de-transaccin, importe (si lo
hubiere) y nuevo saldo.
Descripcin de la funcin actualizar cuenta.
Identificar las restricciones.

Especificar los criterios de optimizacin

Diseo
Arquitectura del Sistema CA
Control de un CA
Pseudocdigo
Hacer para siempre
Mostrar pantalla principal
Leer tarjeta
Repetir
Pedir contrasea
Leer contrasea
Verificar cuenta
Hasta que la verificacin de cuenta sea correcta
Repetir
Repetir
Preguntar clase de transaccin
Leer clase
Leer cantidad
Comenzar transaccin

Esperar que acabe

Hasta que la transaccin sea correcta
Dispensar efectivo
Esperar a que lo tome el cliente
Preguntar si contina
Hasta que el usuario quiera terminar
Expulsar tarjeta
Esperar hasta que el cliente tome la tarjeta
Conclusiones
OMT pone nfasis en la importancia del modelo y uso del modelo para lograr una abstraccin, en el cual el
anlisis est enfocado en el mundo real para un nivel de diseo, tambin pone detalles particulares para
modelado de recursos de la computadora. Esta Tecnologa puede ser aplicada en varios aspectos de
implementacin incluyendo archivos, base de datos relacionales, base de datos orientados a objetos. OMT
est construido alrededor de descripciones de estructura de datos, constantes, sistemas para procesos de
transacciones.
Es muy fcil de aprender ya que para el 90% de casi todos los proyectos se ocupan casi todo el mismo
subconjunto de notaciones, adems debido a su sencillez se ha extendido a casi todo los niveles de ingeniera
de software, pero esta simplicidad del mtodo hace posible que en algunos casos (sobre todo complejos) no
se puedan modelar con este sistema.
Recomendamos esta metodologa como base para aprender mtodos ms modernos y profesionales como
pueden ser UML u Objectory por mencionar algunos.
Esta investigacin dej en nosotros la importancia y las facilidades que brindan el anlisis y diseo orientado
a objetos usando una metodologa en particular, la cual en nuestro caso fue OMT, la cual debido a la poca
prctica con este nuevo paradigma no lo hemos asimilado del todo pero con la prctica de nuestra tercera
parte del proyecto quedarn comprendidas todas estas ideas.

Caso 2
Se necesita un sistema de gestin para un hospital donde, nos permita ingresar
el nombre del paciente y datos personales del mismo, adems de todo su
historial clnico, y de todo el tratamiento que este haya llevado. Tambin se
necesita que el sistema programe citas de los diferentes pacientes que haya,
manejo de las enfermedades de los pacientes, etc.

No

Descripcin

Consultas / Informes
R01

Informe Record de pacientes

R02

Informe Citas por fecha

R03

Informe Citas por paciente por fecha

No

Descripcin

Almacenamiento

R04

Datos de Pacientes:C_PNOMBRE,
C_SNOMBRE, C_PAPELIDO,
C_SAPELLIDO, C_SEXO, D_FNAC,
C_CEDULA, C_TELEFONO,
C_COMPANIA, C_TELCOMPANIA,
D_FREGISTRO

R05

Datos de Citas: C_MOTIVO, N_IDCITA,

D_FREGISTRO, D_FCITA, C_HCITA,
M_NOTA, C_ESTATUS, C_CEDULA.

R06

Datos Encabezado del Records:

N_IDRECORD, C_CEDULA y
D_FREGISTRO

R07

Datos Detalles del Record:

N_IDRECORD,
N_IDDETALLERECORD,
C_TRATAMIENTOMEDICO,
N_IDENFERMEDADESPACIENTE,
N_IDMEDICAMENTOSPACIENTE,
N_IDALERGIASPACIENTE y M_NOTA

R08

Datos por enfermedades de paciente:

N_IDENFERMEDADESPACIENTE,
N_IDENFERMEDAD y M_NOTA

R09

Datos por Medicamentos que toma el

paciente:
N_IDMEDICAMENTOSPACIENTE,
N_IDMEDICAMENTO y M_NOTA

R10

Datos por Alergias que padece el

paciente: N_IDALERGIASPACIENTE,
N_IDALERGIA y M_NOTA

R11

Datos de Enfermedades:
N_IDENFERMEDAD y
C_ENFERMEDAD

R12

Datos de Medicamentos:
N_IDMEDICAMENTO y
C_MEDICAMENTO

R13

Datos de Alergias: N_IDALERGIA y

C_ALERGIA

No

Descripcin

No

Descripcin

Procesamiento

R14

Diagramas de Casos de Uso

Calculo de Edad del Paciente:

( (Fecha del Sistema - D_FNAC) / 365))

Ventajas
1.
Proporciona una serie de pasos perfectamente definidos al desarrollador.
2.

Tratamiento especial de la herencia.

3.

Facilita el mantenimiento dada la gran cantidad de informacin que se genera en el anlisis.

4.

Es fuerte en el anlisis

Desventajas
1.
Hay pocos mtodos para encontrar inconsistencias en los modelos.
2.

Interaccin de objetos no soportada explcitamente en ninguna herramienta grfica.

3.

Al ser un anlisis iterativo es difcil de saber cundo comenzar con el diseo.

4.

Es dbil en el diseo

Aplicaciones
Esta Tecnologa puede ser aplicada en varios aspectos de implementacin incluyendo:
Archivos.

Base de datos relacionales.

Base de datos orientados a objetos.

Estructura de datos.

Multimedia.

Interactivas.

Web.

Cliente/servidor.

Distribuidas.

METODOLOGIA

QUE ES?

CARACTERISTICAS

AUTOR

Fecha de
Implementacin

BOOCH

OOSE

Es una metodologa
que se utiliza en el
anlisis y diseo de
software creada por
Booch durante su
estancia en Rational
Software
Corporation.

Esta metodologa se
Grady
caracteriza por contar con una Booch
notacin expresiva y bien
definida que le permite al
diseador expresar sus ideas y
concentrarse en problemas
ms serios.
Manejo de dimensiones:
* FISICA
* LOGICA
* ESTTICA
> Diagramas de clases
> Diagramas de objetos
> Diagramas de mdulos
> Diagramas de
procesos
* DINAMICA
> Diagrama de transicin
de estados
> Diagramas de
interaccin
Este modelo es la Ivar Jacobson
base en la etapa
de anlisis,
construccin y
prueba.

OOSE brinda un
enfoque para el
manejo de casos
de uso, este
modelo de casos
de uso sirve como
un modelo central Tcnicas OOSE:
para otros
* Modelo de
modelos.
requerimientos
* Modelo de
anlisis
* Modelo de
diseo
* Modelo de
implementacin
* Modelo de
prueba

Este mtodo
proporciona un
soporte para el
diseo creativo de
productos de
software, inclusive
a escala
industrial.
Actividades:
> Modelo de
anlisis
> Construccin
> Diseo
> Prueba del
sistema.

1992

1994

> Desarrollo
incremental