DISEO DE SOLUCIONES

ORIENTADAS A OBJETOS

PROGRAMACIN I/2016

 Para modelar un sistema, siguiendo el

diseo orientado a objetos, se deben
seguir los siguientes pasos:
1.Listar los requerimientos del software.
2.Desarrollar los casos de uso.
3.Diagramar los casos de uso.
4.Moderar las clases.
5.Modelar la interface de usuario.

UML1
Anlisis:
Diagrama de secuencias del sistema
de cada caso de uso
Modelo del Dominio
Diseo:
Diagrama de colaboracin o
diagrama de secuencia

 1. Lista de los requerimientos del

software.
Normalmente la lista de requerimientos se
obtiene luego de una entrevista o varias a
diferentes personas encargadas de llevar
los procesos que se van a informatizar.
En nuestro caso, comprendiendo de la
mejor manera el problema planteado en
un enunciado.

 2. Desarrollo de los casos de

usos
Despus
de
generar
la
lista
requerimientos y obtener una lista de los
usuarios del sistema, el siguiente paso es
desarrollar los casos de uso, los cuales
definirn como el sistema funcionar
desde la perspectiva de los usuarios.

 El primer paso al desarrollar los casos

de uso es definir los actores. Los
actores representan entidades externas
(humanos u otros sistemas) que
interactan con el sistema.

 3. Diagramas de caso de uso.

Cuando ya se han identificado los
diversos actores y casos de uso, se
procede a construir el diagrama de
caso de uso, iniciando con una
versin preliminar del modelo; luego
se buscan otras relaciones que
puedan existir entre los casos de uso.

 4. Desarrollo del modelo de

clases
El desarrollo del modelo de clases
involucra una serie de tareas,
comenzando por la identificacin de
las
clases,
luego
agregar
los
atributos y comportamientos.

 para este fin se comienza por revisar

los casos de uso y los pasos para
llevar a cabo cada uno de ellos.
Es muy importante poder identificar
los nombres o sustantivos que se
encuentran en cada uno de ellos.
Estos son unos buenos indicadores
de que clases deben incluirse en el
desarrollo.

APLICACIN
Una organizacin, no tiene una forma estndar para
que los departamentos hagan sus pedidos de
suministros de oficina, cada departamento
implementa por separado su propio proceso de
pedido. Como resultado de esto, es casi imposible
rastrear el gasto de los suministros de toda la
organizacin, lo cual afecta la capacidad de prever el
presupuesto e identificar los abusos en el gasto. Otro
problema con el sistema actual es que no permite
que una sola persona de contacto pueda negociar
mejores acuerdos con los distintos proveedores.
Desarrollar una aplicacin a nivel de la organizacin
que permita llevar los pedidos de suministro de
oficina.

SOLUCIN

LISTA DE
REQUERIMIENTOS

USUARIOS DEL SISTEMA

Se identifican los siguientes usuarios del
sistema:
o Empleado: inicia un requerimiento de suministros.
o Administrador del departamento: rastrea y
aprueba los requerimientos de suministros para su
departamento.
o Aplicacin del proveedor: recibe las rdenes
generadas por el sistema (en un archivo digital).
o Administrador de compras: actualiza el catlogo
de proveedores, rastrean los requerimientos de
suministro y verifica los tems que se adquieren.

REQUERIMIENTOS
Se identifican los siguientes requerimientos:
o Los usuarios deben poder logearse al sistema
mediante una contrasea y un nombre de usuario.
o Los empleados pueden ver una lista de los
suministros disponibles para poder ordenar.
o Los empleados deben poder filtrar los suministros
mediante una categora.
o Los
empleados
pueden
recibir
suministros en una sola requisicin

mltiples

REQUERIMIENTOS
o El administrador de departamento puede
realizar un requerimiento general para todo
su departamento
o El administrador del departamento debe
aprobar o denegar la requisicin al final de
cada semana.
o Si el administrador del departamento
deniega un requerimiento, deber de aportar
una pequea explicacin de sus razones para
hacerlo.
o El administrador del departamento debe

REQUERIMIENTOS
o El administrador de compras mantiene el
catlogo de proveedores y se asegura que ste
est actualizado.
o El administrador de compras verifica los
suministros recibidos y los organiza para su
distribucin.
o Los requerimientos de suministros que se han
generado pero no han sido aprobados se marcan
como pendientes.
o Los requerimientos de suministros que han sido
aprobados se marcan con el estatus de
aprobados y se genera la orden.

REQUERIMIENTOS
o Una vez una orden es generada, un archivo
conteniendo el detalle de las rdenes es colocado
en la aplicacin del proveedor. Este archivo es
enviado y su estatus es de enviado.
o Una aplicacin separada del proveedor recibe
las rdenes en una cola de prioridad, se distribuye
a
las
lneas
de
distribucin
apropiadas,
peridicamente se estn recibiendo rdenes.
o Cuando se verifican todos los tems de la orden,
la orden se marca con el estatus de completada y
se informa que la orden esta lista para ser llevada.

DESARROLLO DE LOS CASOS

DE USO
Recordar que un caso de uso es un flujo
completo de eventos que ocurren entre el
sistema y las entidades externas a l.
Dichas entidades externas son llamadas actores.
Un caso de uso es por lo tanto una descripcin
de la interaccin que se da entre los actores y el
sistema, en respuesta a un evento que inicia un
actor principal sobre el propio sistema.
La finalidad de un caso de uso es describir la
manera en que se usar un sistema.

DESARROLLO DE LOS CASOS DE

USO
De la lista de requerimientos se han
podido identificar los siguientes
actores que interactan con el
sistema:
Los empleados.
El administrador del departamento.
El administrador de compras.
Aplicacin de procesamiento del
proveedor.

DESARROLLO DE LOS CASOS

DE USO
Luego de haber identificado los actores, el siguiente
paso es identificar los casos de uso en los cuales los
actores se ven involucrados.
Examinando la lista requerimientos se puede
identificar varios casos de uso. Por ejemplo la
sentencia: Los usuarios deben poder logearse al
sistema mediante una contrasea y un nombre de
usuario; Indica la necesidad de crear un caso de usos
llamado Login.
A continuacin se muestran los casos de uso para la
aplicacin que se est construyendo:

CASOS DE USO
NOMBRE: Login
ACTORES: Empleado, Administrador del
departamento, Administrador de compras.
DESCRIPCION: Los usuarios ven la pantalla
de login. Luego digitan su nombre de
usuario y clave de acceso, hacen click en
Entrar o Cancelar, despus de un
acceso exitoso, se ve una pantalla con la
informacin de los productos.

CASOS DE USO
NOMBRE: Ver el catlogo de proveedores
ACTORES: Empleado, Administrador del
departamento, Administrador de compras
DESCRIPCION: Los usuarios ven un listado
de los proveedores en una tabla, dicha
tabla contiene informacin como el nombre
del proveedor, categora, descripcin y
costo. Los usuarios pueden filtrar los
proveedores mediante la categora.

CASOS DE USO
NOMBRE: Requerimiento de compra
ACTORES: Empleado, Administrador del
departamento
DESCRIPCION: El usuario, selecciona los
tems de una tabla mediante un click,
para adicionarlos a la carretilla. Una tabla
separada muestra los tems en la carretilla
con la cantidad requerida, el costo
unitario, y el total del requerimiento.

CASOS DE USO
NOMBRE: Requerimiento de compra de un
departamento
ACTORES: Administrador del departamento
DESCRIPCION: El Administrador del
departamento, selecciona los tems de una
tabla mediante un click, para adicionarlos a la
carretilla. Una tabla separada muestra los
tems en la carretilla con la cantidad
requerida, el costo unitario, y el total del
requerimiento.

CASOS DE USO
NOMBRE: Revisar el requerimiento
ACTORES: Administrador del departamento
DESCRIPCION: El Administrador del
departamento ve una pantalla que lista todos
los requerimientos de provisiones pendientes
de los miembros de su departamento. Revisa
el requerimiento y marca como aprobado o
denegado. Si el requerimiento es denegado,
se debe digitar una pequea explicacin del
por qu.

CASOS DE USO
NOMBRE: Seguimiento del gasto
ACTORES: Administrador del
departamento
DESCRIPCION: El administrador del
departamento ve una pantalla con la
lista mensual de los gastos de los
miembros de su departamento, y el
total de su departamento

CASOS DE USO
NOMBRE: Mantenimiento de catlogo
ACTORES: Administrador de compras
DESCRIPCION: El administrador de
compras tiene la habilidad de actualizar la
informacin de los productos, adicionar
productos o marcar productos como
descontinuados. El administrador puede
adems actualizar la informacin de la
categora, adicionar categoras, y marcar
categoras como descontinuadas.

CASOS DE USO
NOMBRE: Verificar tems
ACTORES: Administrador de compras
DESCRIPCION: El Administrados de
compras, ve una pantalla, digita el
nmero de orden, luego observa una lista
con los tems de las ordenes. Lo tem que
han sido recibidos, se marcan. Cuando
todos los tems de una orden han sido
recibidos, esta se marca como completa.

CASOS DE USO
NOMBRE: Colocar una orden
ACTORES: Aplicacin de
procesamiento del proveedor
DESCRIPCION: El sistema de
procesamiento del proveedor, verifica
en la cola el orden de llegada de los
archivos de pedidos. Se reciben los
archivos y se envan a la cola del
despacho del vendedor.

DIAGRAMA DE CASOS DE USO

Recordar que los Diagramas de Casos de
Uso (DCU) sirven para especificar la
comunicacin y el comportamiento de un
sistema mediante su interaccin con los
usuarios y/u otros sistemas.
En resumen, son diagramas que muestran
la relacin entre los actores y los casos
de uso en un sistema.
A partir de la descripcin de los casos de
uso, se procede a la elaboracin de la
primera aproximacin del diagrama de
casos de uso.

DIAGRAMAS DE CASOS DE
USO

 Cuando se tiene un primer diagrama de

casos de uso, se buscan las relaciones que
puedan existir entre los casos de uso. Dos
de esas relaciones son las de include y
extends. Recordar que cuando un caso
de uso incluye a otro, el caso de uso ser
incluido en la ejecucin como una
precondicin. Por ejemplo, el caso de uso
login, debe incluirse para poder ver el
catalogo.

Login
<<Incluir>
>

Seguimien
to del
gasto

<<Incluir>
>

Ver
catlogo
de
proveedor
es

 una de las razones por las que el

subsistema de login, es un caso de uso, es
porque puede ser reusado por otros casos
de uso.

 La relacin de extensin que existe entre dos casos

de uso, describe una relacin obligatoria del tipo
hace uso, en el que el caso de uso que es
extendido en el caso de uso primario ser realizado
siempre.
En nuestro caso, cuando el administrador est
haciendo un requerimiento de compra, puede indicar
que requiere hacer un pedido para todo el
departamento. Por lo que el caso de uso
Requerimiento de compra puede volverse una
extensin para el caso del uso Requerimiento de
compra de un departamento.

Requerimien
to de
compra de
un
departament
o

<<Extiende>>
Requerimien
to de
compra

 Luego de realizar el anlisis de los

requerimientos del sistema y los
casos de uso, es posible hacer ms
manejable la aplicacin, segregando
el desarrollo en fases. Por ejemplo se
puede
desarrollar
primero
el
requerimiento de Requerimiento de
compra,
luego
Revisar
requerimiento para continuar con
Verificar tems.

DIAGRAMAS DE CASOS DE
USO

DESARROLLO DEL MODELO DE

CLASES
El desarrollo del modelo de clases
involucra una serie de tareas,
comenzando por la identificacin de
las
clases,
luego
agregar
los
atributos y comportamientos.

IDENTIFICAR LAS CLASES

Luego de la identificacin de los casos de uso,
se comienza a identificar las clases de las
necesidades del sistema que deben ser
incluidas, para este fin se comienza por
revisar cada uno de los casos de uso y los
pasos para llevar a cabo cada uno de ellos. Es
muy importante poder identificar los nombres
o sustantivos que se encuentran en cada uno
de ellos. Estos son unos buenos indicadores
de que clases deben incluirse en el desarrollo.

 Por ejemplo, los siguientes pasos describen el caso

de uso: Ver catlogo de proveedores.
1.El usuario que se ha logeado y se le ha asignado un
nivel (esto es una precondicin).
2.Los usuarios ven el catlogo de proveedores, en una
lista. La lista contiene informacin como: nombre
del proveedor, categora, descripcin y costo.
3.Los usuarios pueden filtrar por categora.
4.Los usuarios pueden salir del sistema o hacer un
requerimiento de compra (postcondicin)

 De la anterior descripcin podemos

identificar una clase que ser
responsable de recibir la informacin
del producto desde una base de
datos y filtrar los productos que
estn siendo mostrados. El nombre
podra ser: CatalogoProdcutos.

 Examinando los nombres y frases de

los casos de uso, inferimos las
siguientes clases:

 CASO DE USO: Login

CLASE: Usario, nombreusuario,
password, exito, fallo
CASO DE USO: Ver catlogo de
productos
CLASE: Usuario, lista de producto,
proveedores, informacin, nombre
proveedor, categora, descripcin,
costo

 CASO DE USO: Requerimiento de compra

CLASE: Compra, tems, carretilla, numero,
tem requerido, costo, costo total.
CASO DE USO: Requerimiento de compra
de un departamento
CLASE: Administrador de departamento,
tems, carretilla, numero, tem requerido,
costo, costo total, requerimiento de
compra de departamento

 Ahora que se han identificado las

clases candidatas, Es necesario
eliminar las clases que indican
redundancia. Por ejemplo, una
referencia a tems y lnea de tems
pueden representar la misma
abstraccin. Tambin hay que
eliminar las clases que representan
ms a un atributo que algn objeto.
Usuario, password y costo son

 Algunas clases son vagas O generalizaciones de otras

clases. Usuario es actualmente una generalizacin de
administrador y empleado. Las clases pueden tambin
actuar referente a un mismo objeto pero indicar un
estado
diferente
del
objeto.
Por
ejemplo,
requerimiento de compra y orden representan La
misma abstraccin antes y despus de ser aprobado.
Se debe de filtrar tambin las clases que representan
la implementacin Tal es el caso de listas y tablas .
Por ejemplo una carretilla es realmente una coleccin
de tems de la orden para una orden en particular.

 Usando estos criterios de eliminacin,

podemos reescribir las clases candidatas
como:
Empleado.
AdministradorDepartamento.
Orden.
OrdenItem.
CatalogoProducto
Producto.

 Se pueden incluir tambin clases que

representan los actores con los
cuales interacta el sistema. Estas
son clases especiales llamada clases
de actores y sobre incluidas en el
diagrama para modelar la relacin
entre el sistema y el actor.

 Una
primera
modelo seria:

aproximacin

del

Comprar
(UI)

Orden

Empleado

OrdenItem

Product
o

CatalogoProdu
cto

AdministradoDepartam
ento

 La siguiente etapa en el desarrollo

del modelo de clases es identificar el
nivel de abstraccin de las clases
que se deben implementar. Se debe
determinar el estado de la
informacin relevante para la
aplicacin. Este requerimiento ser
implementado a travs de los
atributos de las clases.

 Analizando los requerimientos del sistema

para la clase empleado, se revela la
necesidad de tener atributos como nombre
de usuario, password y departamento.
Tambin se necesitan identificar al empleado
mediante un ID nico que identifique a
varios empleados. En una entrevista con los
administradores se revela la necesidad de
incluir sus nombres y sus apellidos para
puede rastrear los pedidos por el nombre.

 CLASE:
Empleado
ATRIBUTO Y TIPO :
EmpleadoID
int
NombreLogin
Password

string

Departamento
Nombre
Apellidos

string

string
string
string

 CLASE:
AdministradorDepartamento
ATRIBUTO Y TIPO :
EmpleadoID
int
NombreLogin
Password

string

Departamento
Nombre
Apellidos

string

string
string
string

CLASE:
Orden
ATRIBUTO Y TIPO :
NumeroOrden
long

FechaOrden
Status

Date
string

CLASE:
OrdenItem
ATRIBUTO Y TIPO :
CodigoProdcuto
string

Cantidad
PrecioUnitario

int
decimal

CLASE:
Producto
ATRIBUTO Y TIPO :
CodigoProducto
string

NombreProducto
Descripcion
PrecioUnitario
Categoria
CodigoProveedor

string
string
decimal
string
string

CLASE:
CatalogoProducto
ATRIBUTO Y TIPO :
Nada

 Luego de hacer un anlisis de las

clases y de eliminar los datos que no
son necesarios tenemos:

EMPLEADO
EmpleadoID
NombreLogin
Password
Departamento
Nombre
Apellidos

int
string
string
string
string
string

PRODUCTO
CodigoProducto
NombreProducto

string
string

Descripcion
PrecioUnitario

decimal

Categoria
CodigoProveedor

string
string

string

ORDEN
NumeroOrden
FechaOrden
Status

long
Date
string

ORDENITEM
CodigoProdcuto
Cantidad
PrecioUnitario

string
int
decimal

ADMINISTRADORDEPARAMENTO

CATALOGOPRODUCTO

COMPRARUI

 La siguiente etapa del proceso para modelar

las clases es identificar las asociaciones,
stas se derivan de los requerimientos del
sistema.
Por ejemplo, un empleado debe ser asociado
a una orden. Para verificar la multiplicidad de
la asociacin, se descubre que un empleado
puede realizar mltiples rdenes, pero una
orden puede ser asociada solamente a un
empleado. De la siguiente manera:

Empleado

1 Hace 0
.. n

Orden

 Tan pronto como se comienza a identificar

los atributos de las clases, se notar que la
clase
Empleado
y
la
clase
AdministradorDepartamento
tienen
los
mismos atributos. Esto tiene sentido ya que
los administradores tambin son empleados.
Para propsitos de esta aplicacin, un
administrador representar un empleado
con un comportamiento especializado. Esta
especializacin ser representada por una
relacin de herencia como se muestra:

Empleado
<<
inherits>>
AdministradorDeparta
mento

 Las siguientes sentencias indican una

determinada relacin de asociacin
entre la estructura de las clases:
1.Una Orden es una coleccin de
objetos de OrdenItem.
2.Un Empleado tiene mltiples objetos
del tipo Orden.
3.Una Orden es asociada con un solo
Empleado.
4.El CatalogoProducto es asociado con
mltiples objetos del tipo Producto.

1.Un producto es asociado con

CatalogoProducto.
2.Una OrdenItem es asociada con un
Producto.
3.Un Producto puede ser asociado con
mltiples objetos OrdenItem.
4.Un AdministradorDepartamento es un
empleado como un comportamiento
especializado.

 El diagrama quedara de la siguiente

manera:

1 Comprar( 1
UI)

AdministradorDepartam <<
inherits>>
ento

Empleado
1

Realiz
0..
a

CatalogoProduc
to

n
Orden

1
Contien
e
1..n
Producto

1..
n Contie

Contie
ne
1

1..
n
OrdenItem

 En este punto en la aplicacin, se

comienza a desarrollar el diseo de la
interfaz grfica de usuario (GUI), este
modelaje conlleva a crear prototipos
de esas interfaces que se utilizan
para verificar el diseo de la lgica
del negocio que ha sido creado.
Adems ayuda a los usuarios a
interactuar con el prototipo y a recibir
retroalimentacin y verificacin de la
lgica empleada.

 El primer prototipo que se necesita

implementar es el login, podemos
construir a partir de seudo-codigo las
actividades que esta pantalla va a
realizar.
1.El usuario digita su nombre
2.El usuario digita su password
3.Presiona el botn Ok
4.Si la contrasea y el nombre son
vlidos, presenta la pantalla inicial
del sistema, de lo contrario va al
punto No. 1.

 Otra pantalla que es necesaria, es la

pantalla de catlogo de producto que
tendr un comportamiento de la siguiente
manera:
1.El usuario selecciona la categora
2.Se presenta el listado de los productos
pertenecientes a esa categora, se habilita
para realizar otra bsqueda por categora
3.El usuario puede iniciar una orden o
puede cancelar la pantalla e ir a la
pantalla inicial del sistema

 Una pantalla final, a ser diseada es

el carro de compras, esta facilitar
adicionar y remover tems a una
orden, tambin es necesario que el
usuario pueda enviar o cancelar la
orden.