CASO USO 02-Gestión de Pedidos

UNP - Análisis de Sistemas Caso Práctico
SISTEMA DE GESTIÓN DE PEDIDOS
PROPUESTA
El sistema deberá realizar la solicitud automática de productos, según el nivel mínimo establecido para cada tipo
de producto para conseguir un aprovisionamiento a nivel normal (similar a como se hace en los comercios), y
sujetos a las restricciones temporales establecidas por los proveedores y comerciantes.
Un operario también puede decidir realizar un pedido a proveedor.
El sistema deberá evitar la duplicidad de pedidos.
Todos los pedidos han de ser aprobados, y pueden ser modificados, por el responsable de abastecimiento.
Éste es el encargado de solucionar los conflictos que puedan aparecer, como por ejemplo, que un comerciante
necesite un pedido lo antes posible y el proveedor no lo entregue hasta dentro de una semana. En este caso
deberá decidir si tramitar un pedido especial, consultado, si es necesario, al comerciante.
El proceso de negocio arranca cuando el sistema decide de forma automática realizar un pedido a proveedor o
cuando un operario lo indica de forma explícita en el sistema de información. Tanto el sistema, como el operario,
estarían jugando el rol de solicitante de pedido a proveedor.
Por otro lado, el responsable de abastecimiento es el encargado de aprobar los pedidos y resolver los conflictos.
Cuando un pedido es aprobado, es comunicado al proveedor. Éste tramitará el pedido y lo entregará al centro de
distribución. Esto último no aparece de forma explícita en la práctica, pero se sobreentiende dentro del contexto
en el que se encuentra. Uno de los operarios se encargará de recibir los pedidos de los proveedores.
SOLUCION
Este caso práctico pretende guiar el proceso de modelamiento del análisis desde las fases relativas a la
obtención y descripción de los procesos de negocio hasta el diagrama de clases.
Se ha divido en las siguientes etapas:
Modelado del Negocio

1. Establecer las acciones necesarias para realizar el proceso de negocio
2. Establecer las acciones necesarias para realizar el proceso de negocio.
3. Construir un diagrama de actividades que represente el proceso de negocio
4. Listar las Actividades
5. Listar las Reglas de negocio
Modelado de Requisitos.
1. Identificar Casos de uso
2. Describir los casos de uso.
3. Crear el Modelo Conceptual.
Modelado de Análisis y Diseño.

1. Diagramas de secuencia de sistema.
2. Evolucion de los diagramas de secuencia
3. Diagrama de clases
Ing. Esther Lizana Puelles 1

MODELADO DE NEGOCIO
En general, podemos considerar un proceso de negocio como un objetivo estratégico de la organización. Con la
descomposición en procesos de negocio pretendemos identificar las actividades de alto nivel que desarrolla la
empresa. No debemos confundir un subsistema de información de la empresa con un proceso de negocio. Por
ejemplo, la sección dedicada al Centro Comercial Virtual no es un proceso de negocio de la empresa en sí. Es
una parte del sistema de información que hará de intermediario entre el cliente de la empresa y la propia
empresa. La funcionalidad estará repartida en varios procesos de negocio: Comprar, Devoluciones, etc. que
implican a otros subsistemas de la empresa
Paso 1. Identificar los agentes implicados en el proceso de negocio.
Los agentes implicados en el proceso de negocio son:

 Solicitante pedido a proveedor.
 Responsable de abastecimiento.
 Operario.
 Proveedor.
Paso 2. Establecer las acciones necesarias para realizar el proceso de negocio.
Podemos abordar este apartado tratando de describir de forma informal la interacción entre roles necesaria para
que se cumpla el proceso de negocio con éxito. Un ejemplo de interacción entre roles podría ser:
o El solicitante del pedido realiza un pedido en el sistema.
o El pedido es enviado al responsable de abastecimiento para su evaluación. Éste podrá decidir
modificarlo o no. Independientemente de lo que haga, deberá decidir si aprueba el pedido. Si lo
aprueba, enviará la solicitud de pedido al proveedor.
o El proveedor tramitará el pedido y lo entregará en el plazo establecido en la solicitud.
o Un operario se encargará de registrar la llegada del pedido, cuando llegue al centro de distribución
En la secuencia de acciones anterior podemos identificar las acciones que realiza cada agente. A continuación
mostraremos una lista de los agentes y las acciones que realiza cada uno de ellos:
 Solicitante de pedido a proveedor:
- Realizar pedido a proveedor.
 Responsable de abastecimiento.
- Evaluar pedido.
- Modificar pedido.
- Aprobar pedido.
- Rechazar pedido.
 Proveedor:
- Tramitar pedido.
 Operador:
- Registrar la llegada de un pedido.
Paso 3. Construir un diagrama de actividades que represente el proceso de negocio.
Haciendo uso de los elementos de los diagramas de actividades de UML trataremos de mostrar de forma más
rigurosa y ordenada el flujo de actividades del proceso de negocio.

Las acciones del proceso de negocio intercambian una única información: un pedido. En este caso, el pedido
fluiría entre las acciones cambiando de estado. También debemos destacar que el proveedor queda fuera de la
organización. Aunque para tramitar un pedido necesite conocer el pedido, este conocimiento lo obtendrá a través
de una orden de pedido o cualquier otro documento. Este documento será el que entregue al operario cuando
haya que registrar la llegada del pedido.
Paso 4. Listar las actividades.
La lista de actividades que se realizan en el proceso de negocio son las siguientes:

- Realizar pedido.
- Evaluar pedido.
- Modificar pedido.
- Aprobar pedido.
- Rechazar pedido.
- Registrar llegada de pedido.
Ha sido omitida la acción Tramitar pedido, ya que queda fuera de nuestro sistema de información. Aunque esto
fue decidido desde el principio, se mostrará en el diagrama de actividades para dar continuidad a todas las
actividades del sistema relacionadas en el proceso de negocio.
Es interesante dar una lista de actividades porque, en general, cada una de esas actividades estará asociada a
un caso de uso. También deberemos dar una especificación de las actividades. La especificación de las
actividades nos ayudará a comprenderlas y a detectar ambigüedades en los requerimientos en una fase
temprana del desarrollo.
Paso 5. Listar las Reglas de negocio.
Podemos considerar las reglas de negocio como una serie de restricciones de la organización a la hora de
realizar una determinada actividad. También pueden aparecer asociadas a una información, como restricciones
de integridad.

En nuestro proceso de negocio podemos identificar tres.

Dos que afectan a la forma de realizar los pedidos y una que establece el modo de resolver los conflictos en los
pedidos.
Por lo tanto, las tres reglas de negocio para este proceso son:
1. Cuando se realice un pedido a proveedor debe especificarse la cantidad necesaria para llegar al nivel
normal de stock a partir de la cantidad actual.
2. Deberá evitarse la duplicidad de pedidos. No deben existir dos pedidos a proveedor para un mismo
producto.
3. Cuando aparezca un conflicto con algún pedido de un asociado, el responsable de abastecimiento
deberá consultar con el asociado la forma de resolver el conflicto: esperar a que lleguen los productos,
según su frecuencia de distribución, o realizar un pedido especial.
MODELADO DE REQUISITOS
Paso 1. Identificar Casos de uso.
Una vez realizado el modelo de negocio, construimos un diagrama de casos de uso a partir de los diagramas de
actividades. Podemos considerar cada actividad como un caso de uso y el agente que la realiza como el actor del
caso de uso.
Recomendaciones:
o En general, no conviene buscar relaciones extend o include entre los casos de usos, a no ser que
resulten muy evidentes. Estas relaciones irán apareciendo conforme desarrollemos las plantillas de los
casos de uso. Por ejemplo, si Aprobar pedido permitiera modificar los datos del pedido antes de su
aprobación, incluiríamos una relación include entre Aprobar pedido y Modificar pedido.
o En general, hay que evitar una descomposición funcional excesiva del diagrama de casos de uso, es
decir, si un caso de uso consta de varios pasos o etapas, no hay que definir un caso de uso para cada
uno de esos pasos y una relación include entre el caso de uso original y los nuevos. Solo en situaciones
en las que dos o más casos de uso posean una etapa en común, podríamos considerar su
factorización.
Un diagrama inicial de casos de uso para el proceso de negocio quedaría de la siguiente manera:

Paso 2. Describir los casos de uso.
Para la descripción de los casos de uso podemos utilizar plantillas. Cada cual puede definirse sus propias
plantillas, siempre y cuando utilice las mismas durante todo el proyecto y todos los miembros del equipo de
desarrollo sepan interpretarlas.
A continuación proponemos la plantilla de casos de uso que utilizaremos en este documento:
Caso de uso: nombre del caso de uso

Objetivo: descripción informal de los objetivos del caso de uso
Actores: actores que intervienen en el caso de uso: principales y secundarios
Precondiciones: condiciones que deben cumplirse para que pueda realizarse el caso de uso
Pasos: secuencia de pasos necesarios para que el caso de uso se desarrollo con éxito. Debemos mostrar las
interacciones de los actores (A) y las acciones del sistema (S).
Variaciones: variaciones en la secuencia de pasos.
Extensiones: puntos de extensión del caso de uso.
Cuestiones: cuestiones planteadas durante la especificación del caso de uso

Utilizando la plantilla anterior, pasamos a documentar cada uno de los casos de uso.
CU1. Realizar pedido.
Caso de uso: Realizar pedido

Objetivo: realizar un pedido a proveedor con la cantidad necesaria del producto para conseguir un nivel de stock
normal, evitando la duplicidad de pedidos.
Actores: Solicitante de pedido
Precondiciones:
Pasos:
1. A: Indicar el producto para el que se va a realizar el pedido.
2. S: Comprobar que no exista un pedido para ese producto.
3. S: Calcular la cantidad a pedir.
4. S: Registrar el pedido.
Variaciones:
2.a. Existe un pedido para el producto:
2.a.1. Indicar error.
2.a.2. Finalizar cdu (caso de uso)
Extensiones:
1. Modo de realizar el pedido: automático o manual.
Cuestiones:
1. ¿Puede el actor modificar la cantidad calculada por el sistema?
Revisión con el cliente:

En este punto habría que consultar al cliente la decisión. Supongamos que el cliente decide que el operador
puede modificar la cantidad a pedir, pero siempre por debajo de la cantidad máxima. Esta variación se expresará
como un porcentaje respecto a la cantidad máxima.
El apartado referente a las extensiones nos dice que existen dos modos distintos de realizar un pedido,
automático o manual.
o En el modo automático no se podrá modificar la cantidad a pedir, mientras que en el modo manual sí.
o En el modo manual, el actor deberá confirmar el pedido, para indicar así que no va a realizar más
modificaciones.
Teniendo en cuenta todo lo anterior, aparecen dos nuevos casos de uso:
Caso de uso: Realizar pedido manual extiende Realizar pedido

normal, evitando la duplicidad de pedidos y permitiendo cierta modificación
Precondiciones:
Pasos:
3. S: Calcular la cantidad a pedir
4. A: [Repetir de 0..n] Modificar la cantidad a pedir.
5. A: Confirmar el pedido.
Variaciones:
4.a. Cantidad introducida no está dentro de los límites.
4.a.1. No permitir la modificación.
Extensiones:
Cuestiones:
Debemos destacar la declaración “[Repetir de 0..n]”, que indica simplemente que el actor puede repetir la acción
cero o más veces.

Caso de uso: Realizar pedido automático extiende Realizar pedido

normal, evitando la duplicidad de pedidos.
Precondiciones:
Pasos:
3. S: Calcular la cantidad a pedir
Variaciones:
Extensiones:
Cuestiones:
CU2. Modificar pedido.
Caso de uso: Modificar pedido

Objetivo: modificar la cantidad de un pedido a proveedor
Actores: Responsable de abastecimiento
Precondiciones:
Pasos:
1. A: Indicar la nueva cantidad del pedido.
Variaciones:
Extensiones:
Cuestiones:
1. ¿Puede realizar un pedido que sobrepase la cantidad máxima en stock.?
2. ¿Cuál es la cantidad máxima de stock para un producto?

Volvemos a consultar con el cliente la respuesta a las cuestiones que han surgido. Nos dice que el sistema
deberá evitar que el responsable de abastecimiento solicite una cantidad que no pueda almacenarse en el centro
de distribución, es decir, que no sobrepase la cantidad máxima y que podemos suponer que la cantidad máxima
en stock de un producto es lo que en la especificación se llama “nivel normal”. El caso de uso quedaría del
siguiente modo:
Caso de uso: Modificar pedido

Objetivo: modificar la cantidad de un pedido a proveedor sin que sobrepase el nivel normal
Precondiciones:
Pasos:
1. A: Indicar la nueva cantidad del pedido.
Variaciones:
1.a. Cantidad introducida sobrepasa la cantidad máxima (nivel normal) en el momento actual.
1.a.1. S: Rechazar la modificación.
Extensiones:
Cuestiones:
CU3. Aprobar pedido.
Caso de uso: Aprobar pedido

Objetivo: aprobar un pedido a proveedor y comunicar al proveedor la solicitud del pedido
Precondiciones:
Pasos:

1. A: Aprobar el pedido.
2. A: Comunicar al proveedor la solicitud del pedido.
Variaciones:
Extensiones:
1. Modo de comunicación con el proveedor.
Cuestiones:
1. ¿Qué modos de comunicación tenemos con el proveedor?

Consultamos de nuevo al cliente para aclarar la cuestión.
El cliente nos dice que la comunicación con el proveedor debe realizarse de dos formas:
1. Por Fax: preferentemente por fax. En el fax aparecerá toda la información relativa al pedido: número de
pedido, fecha y hora de emisión (aprobación), fecha y hora de recepción, el producto, la cantidad y si es
o no especial.
2. Por correo electrónico: Si no es posible enviar la orden de pedido por fax, se le enviará por correo
electrónico. Lo que se pretende es que el proveedor disponga de algún documento que identifique al
pedido durante la entrega.
Después de la aclaración del cliente podríamos pensar en crear dos nuevos casos de uso que extendieran al
caso de uso base, Aprobar pedido.
Este planteamiento además permitiría incluir nuevos modos de comunicar un pedido a un proveedor, como por
ejemplo, entregar la nueva orden de pedido en mano durante alguna entrega.
El problema que surge con estos dos nuevos casos de uso es que tendrían nombres como Aprobar pedido y
comunicarlo por fax.
Resulta más claro separar el caso de uso base en dos: Aprobar pedido, propiamente dicho, y Comunicar pedido,
existiendo una relación include entre ellos.

Objetivo: aprobar un pedido a proveedor y comunicar al proveedor la solicitud del pedido
Precondiciones:
Pasos:
1. A: Aprobar el pedido.
2. A: cdu Comunicar pedido.
Variaciones:
Extensiones:
Cuestiones:
Caso de uso: Comunicar pedido

Objetivo: comunicar un pedido a un proveedor
Precondiciones:
Pasos:
1. A: Comunicar pedido.
Variaciones:
Extensiones:
1. Modos de comunicación con el proveedor.
Cuestiones:
Caso de uso: Comunicar pedido por fax extiende Comunicar pedido

Objetivo: comunicar un pedido a un proveedor por fax
Precondiciones:
Pasos:
1. A: Comunicar pedido por fax
Variaciones:
1.a. El proveedor no dispone de fax.
1.a.1. Indicar el error.
Extensiones:

Cuestiones:
Caso de uso: Comunicar pedido por e-mail extiende Comunicar pedido

Objetivo: comunicar un pedido a un proveedor por e-mail
Precondiciones:
Pasos:
1. A: Comunicar pedido por e-mail
Variaciones:
1.a. El proveedor no dispone de e-mail.
1.a.1. Indicar el error.
Extensiones:
Cuestiones:
CU4. Registrar llegada de pedido.
Caso de uso: Registrar llegada de pedido

Objetivo: registrar la llegada de un pedido a proveedor, verificando que el pedido esté en espera, y actualizar el
stock
Actores: Operario, Proveedor
Precondiciones:
Pasos:
1. A Proveedor: Identificación.
2. A Proveedor: Entrega la hoja de pedido (fax o documento enviado por correo electrónico)
3. A Operario: Solicita los pedidos pendientes del proveedor.
4. A Operario: Verifica el pedido
4.1. Verifica que el pedido se estaba esperando.
4.2. Verifica la cantidad.
4.3. Verifica la fecha y hora de recepción.
5. A Operario: Confirma la recepción.
6. S: Actualiza el stock.
Variaciones:
4.1.a. El pedido no se estaba esperando.
- ¿?
4.2.a. La cantidad es inferior a la esperada.
- ¿?
4.3.a. El momento de recepción es posterior al esperado.
- ¿?
Extensiones:
Cuestiones:
1. ¿Qué hacer con los pedidos que no esperamos?
2. ¿Qué hacer cuando la cantidad es inferior a la esperada?
3. ¿Qué hacer si el momento de recepción es posterior al esperado?

Ante las cuestiones anteriormente planteadas, el cliente nos da las siguientes respuestas.
o Si llega un pedido no esperado, habrá que notificarlo al responsable de abastecimiento. Este decidirá si
aceptarlo o no.
o Si lo acepta, deberá registrarse como una variación extraordinaria del stock.
o Por otro lado, si la cantidad es inferior a la esperada, el operario aceptará el pedido y notificará la
situación al responsable de abastecimiento.
o Por último, si el momento de recepción es posterior al esperado, el operario aceptará el pedido y, de
nuevo, lo notificará al responsable de abastecimiento.
Las nuevas consideraciones provocan modificaciones en el diagrama de actividades del proceso de negocio que
se modelarían con una decisión que podría llevar a las siguientes acciones:
1. Estado final, que representaría una recepción correcta del pedido.

2. Evaluar pedido inesperado, que se realizaría después de que el operario enviara la notificación al
responsable de abastecimiento. A su vez, esta acción llevaría a dos nuevas acciones, dependiendo de la
decisión que tome el responsable de abastecimiento después de la evaluación
a. Aceptar pedido inesperado
b. Rechazar pedido inesperado
Finalmente, todos estos cambios nos conducirían a la creación de tres nuevos casos de uso, Evaluar pedido
inesperado, Aceptar pedido inesperado y Rechazar pedido inesperado.
El caso de uso Evaluar pedido inesperado es simplemente la recepción de la notificación y la decisión.
A continuación mostramos las plantillas de los otros dos casos de uso:
Caso de uso: Aceptar pedido inesperado

Objetivo: aceptar la llegada de un pedido inesperado y registrarlo como variación extraordinaria del stock
Precondiciones:
Pasos:
1. A: Acepta el pedido inesperado.
2. S: Registrar variación extraordinaria de stock
Variaciones:
Extensiones:
Cuestiones:
Caso de uso: Rechazar pedido inesperado

Objetivo: rechazar la llegada de un pedido inesperado llegado al centro de abastecimiento
Precondiciones:
Pasos:
1. A: Rechazar pedido inesperado.
Variaciones:
Extensiones:
Cuestiones:
Especificación relacionada con los pedidos conflictivos.
En la especificación del proceso de negocio se menciona que el responsable de abastecimiento debe intentar
resolver los pedidos conflictivos. Pero la especificación no describe lo que son los pedidos conflictivos.
Siguiendo la norma de “no inventar requisitos” consultamos con el cliente el significado de los pedidos
conflictivos. Según el cliente podemos considerar un pedido como conflictivo cuando existe un pedido de algún
asociado en el centro de distribución que no puede ser servido con el stock actual y no podrá ser servido a tiempo
con una solicitud de pedido formal al proveedor del producto en cuestión. Se origina por la restricción de tiempo
que establece el asociado.
Por ejemplo:
Un asociado ha solicitado 50 paquetes de 500 folios A4 al centro de distribución teniendo como fecha máxima de
entrega el viernes.
La solicitud de pedido llega el miércoles y en este momento no existe stock suficiente para completar el pedido.
Supongamos que sólo existen 10 paquetes, cuando el nivel mínimo es 20, y se ha realizado un pedido a
proveedor.
Existiría un conflicto si la fecha de recepción del pedido fuera posterior a la fecha máxima de entrega indicada por
el asociado, es decir, el viernes.
¿Quién debe realizar los pedidos conflictivos?

El cliente responde a esta pregunta diciendo que es demasiada responsabilidad para un operario el detectar los
conflictos. El sistema deberá informar a los operarios sobre la existencia de conflictos, pero ha de ser el mismo
Centro de Distribución el que realice un pedido especial para completar el pedido del comerciante asociado,
manteniendo la asociación entre ambos.

Los nuevos casos de uso que aparecen son los siguientes:
Caso de uso: Realizar pedido conflictivo

Objetivo: realizar una solicitud de pedido a proveedor y asociarle el pedido de asociado conflictivo
Actores: Centro de Distribución
Precondiciones:
1. El pedido del asociado debe estar en conflicto
Pasos:
1. A: Identifica el pedido de asociado en conflicto
Variaciones:
Extensiones:
Cuestiones:
Caso de uso: Resolver conflicto

Objetivo: resolver el conflicto entre la restricción de tiempo establecida por el asociado y la frecuencia de
distribución del proveedor
Actores: Responsable de abastecimiento (principal), Comerciante (secundario)
Precondiciones:
Pasos:
1. A Proveedor: Informa al comerciante sobre el conflicto.
2. A Comerciante: Decide seguir con el pedido
2.1.S. Tramitar un “pedido especial a proveedor”.
3. A. Comerciante: Decide esperar
3.1. S. Modificar la restricción de tiempo del pedido del asociado.
Variaciones:
Extensiones:
Cuestiones:
A continuación mostramos el caso de uso Tramitar Pedido especial a proveedor.
Caso de uso: Tramitar Pedido especial a proveedor

Objetivo: Realizar un pedido especial a proveedor asociado a un pedido de comerciante
Precondiciones:
Pasos:
1. A. Indica el pedido del asociado.
2. S. Crea un pedido especial para el pedido del asociado.
2.1. S. Si es necesario, modifica la cantidad del pedido para que se ajuste al valor mínimo de pedido especial
negociado con el proveedor.
3. S. cdu Comunicar pedido
Variaciones:
Extensiones:
Cuestiones:
Podemos ver que el anterior caso de uso está relacionado con Comunicar pedido mediante la relación include. El
caso de uso Comunicar pedido se definió para los pedidos normales. Podemos utilizar el mismo caso de uso ya
que un pedido especial es una especialización de pedido.
El proceso que hemos seguido hasta este momento ha sido partir de las actividades del diagrama de actividades
del proceso de negocio para construir un diagrama inicial de casos de uso.
Después hemos rellenado las plantillas para cada uno de ellos y hemos visto cómo van surgiendo nuevos casos
de uso y nuevas relaciones entre ellos.
También hemos identificado una ambigüedad de la especificación relacionada con los pedidos conflictivos.
Finalmente nos queda el siguiente diagrama de casos de uso:

Priorización de Casos de uso

Una vez identificados todos los casos de uso, hay que priorizarlos.
El cliente decidirá la funcionalidad que necesita ser desarrollada primero. Los casos de uso en los que nos
centraremos en el primer ciclo de desarrollo son los siguientes:
 Realizar pedido manual.
 Modificar pedido.
 Aprobar pedido.
 Rechazar pedido.
 Comunicar pedido por fax.
 Registrar llegada de pedido.
Es importante dar prioridades a los casos de uso y simplificarlos, si son excesivamente complejos. Los casos de
uso guían el proceso de desarrollo. En el siguiente ciclo de desarrollo, habría que tener en cuenta las
simplificaciones realizadas en el primer ciclo e incluir los casos de uso que hayamos dejado pendientes, y así
hasta modelar completamente el sistema.
Paso 3. Crear el modelo conceptual.
Comenzamos a construir el modelo conceptual a partir de la lista de informaciones que hemos obtenido del
diagrama de actividades.
En este proceso de negocio la única información que fluye entre las actividades es el pedido, estando en
diferentes estados según la transición, siendo sus atributos proveedor, cantidad y producto. Por lo tanto,
identificamos los siguientes conceptos iniciales: Pedido, Proveedor y Producto.
El siguiente paso es encontrar más conceptos a partir de la descripción de los casos de uso.
Utilizando la técnica de identificación de nombres podemos encontrar los siguientes conceptos (del libro UML y
Patrones, Craig Larman):
o Solicitante de Pedido,
o Responsable de Abastecimiento,
o Operario,
o Proveedor,
o Comerciante,
o Pedido,
o Pedido especial,
o Pedido asociado,

o Producto,
o Centro Distribución y
o Stock.
Veamos ahora las asociaciones. No es tan importante a este nivel del análisis el encontrar todas las
asociaciones. Identificaremos sólo las necesarias. El resto irán surgiendo cuando realicemos los diagramas de
interacción.
 Solicitante de pedido - Solicita - Pedido

 Responsable de abastecimiento - Aprueba/Rechaza/Modifica - Pedido
 Operario - Registra llegada - Pedido
 Proveedor - Sirve - Pedido
 Registro de pedidos - Contiene - Pedidos
 Pedido - Asociado - Producto
 Pedido especial - Está asociado - Pedido Asociado
 Pedido Asociado - Realizado por - Asociado
 Centro de Distribución - Posee - Registro de pedidos
 Centro de Distribución - Posee - Catálogo
 Centro de Distribución - Posee - Stock
 Centro de Distribución - Tiene contrato - Proveedor
 Proveedor - Suministra - Producto
También hemos identificado una relación de generalización entre Pedido y Pedido Especial. Cuando estamos
construyendo el modelo conceptual no nos debe preocupar encontrar relaciones de generalización,
multiplicidades, etc., pero en este caso como Pedido Especial está asociado a los mismos conceptos que Pedido
y tiene los mismos atributos, hemos decidido mostrar la generalización.
Después debemos identificar los atributos de los conceptos. En la especificación sólo se hace referencia a los
siguientes atributos:
 Stock: cantidad, nivel mínimo, nivel normal.

 Pedido: cantidad.
 Pedido asociado: cantidad.
 Pedido especial: cantidad.
El resto de atributos irán apareciendo durante las siguientes fases del desarrollo.
Por último, debemos construir un glosario de términos. Los casos de uso ya están documentados con sus
plantillas. Ahora es necesario documentar todos los conceptos y atributos del modelo conceptual.


MODELADO DE ANÁLISIS Y DISEÑO
Paso 1. Diagrama de Secuencia del sistema.
En este punto trataremos de determinar las operaciones que demandan los actores del sistema. Para ello
construiremos los llamados Diagramas de Secuencia de Sistema, que consisten en diagramas de secuencia, en
los que sólo intervienen los actores del caso de uso y un objeto que representa al sistema, donde se muestran los
eventos (operaciones) que envían los actores al sistema. Creamos un diagrama de secuencia de sistema para
cada caso de uso.
1. Realizar pedido manual.
2. Modificar pedido.

3. Aprobar pedido.
4. Rechazar pedido.
5. Comunicar pedido
6. Registrar llegada de pedido

Paso 2. Evolución de los diagramas de secuencia.
Debemos crear un diagrama de secuencia para cada operación que nos ha aparecido en los diagramas de
secuencia de sistema. El modo de proceder es el siguiente. Primero crearemos un contrato para cada una de las
operaciones.
El contrato nos ayudará a precisar la funcionalidad de la operación. Como ya ocurriera con las plantillas de los
casos de uso, podemos definir cualquier tipo de plantilla para definir las operaciones. Es conveniente que en la
plantilla que utilicemos aparezcan dos apartados: responsabilidades y postcondiciones.
o Responsabilidades: El primero de ellos trate de determinar el ámbito de la operación, es decir,
determinar la responsabilidad de la operación.
o Postcondiciones: El segundo nos informa de las modificaciones del estado del sistema (objetos y
relaciones entre los objetos) después de que la operación se ejecute correctamente. Con las
postcondiciones estamos indicando qué es lo que esperamos, pero no cómo conseguirlo.
La plantilla que proponemos para definir los contratos es la siguiente:
Nombre: signatura de la operación

Responsabilidades:
Tipo: clase controlador que realiza la operación
Caso de uso: nombre del caso de uso al que pertenece la operación
Notas: requisitos no funcionales
Excepciones:
Salidas: salidas fuera del sistema, sin tener en cuenta las salidas por pantalla
Precondiciones: condiciones que han de cumplirse para realizar la operación
Postcondiciones: estado del sistema después de realizar la operación
Caso de uso: Realizar pedido manual a proveedor.
 nuevoPedidoProveedor
Nombre: nuevoPedidoProveedor(producto: Producto): Pedido

Responsabilidades: deberá crear un nuevo pedido a proveedor con la cantidad necesaria para llegar al nivel
normal del stock del producto. Establecerá el estado del pedido como “no confirmado solicitante”
Tipo: Centro de Distribución
Caso de uso: Realizar pedido manual a proveedor
Notas:
Excepciones:
Salidas:
Precondiciones:
- El producto debe existir.

Postcondiciones:
- Un objeto Pedido es creado.
- Pedido.cantidad = Stock.nivelNormal - Stock.cantidad
- Pedido.estado = “no confirmado solicitante”.
- Se establece la asociación Registro Pedidos y Pedido
Una aspecto importante en la colaboración es determinar cuál será la clase controlador. Hemos decidido que sea
la clase Centro de Distribución, que representa al sistema. Otra elección podría haber sido la clase
ManejadorRealizarPedido, pero sería una clase ficticia con el único propósito de manejar los eventos del caso de
uso Realizar Pedido. Deberíamos optar por esta segunda opción cuando el caso de uso requiera controlar un
estado (no se pueden realizar unas operaciones antes que otras), cuando la inclusión de las operaciones en la
clase que representa al sistema haga que ésta pierda cohesión (relación entre sus operaciones) o que contenga
demasiadas operaciones.
En el anterior diagrama de secuencia mostramos los mensajes que hay que enviar para conseguir la
funcionalidad de la operación. Cada uno de esos mensajes supone la ejecución de un método en alguno de los
objetos implicados en la colaboración. Sería conveniente definir un contrato para las operaciones más complejas,
e incluso, definir su propio diagrama de secuencia. Todo ello con el propósito de no complicar los diagramas de
secuencia.
Caso de uso: Comunicar Pedido.
 comunicarPedidoPorFax
Nombre: comunicarPedidoPorFax(pedido: Pedido)

Responsabilidades: enviar la orden de pedido al proveedor por fax
Tipo: Centro de Distribución
Notas:
Excepciones:
Salidas:
Precondiciones:
- Estado del pedido = “aprobado”
Postcondiciones:
- pedido.estado = “comunicado”

Se debe seguir el mismo camino para cada una de las operaciones definidas en los diagramas de
secuencia.
•Realizar pedido manual.
nuevoPedidoProveedor(Producto) (Elaborado)
modificarPedidoProveedor(Pedido, Cantidad)
confirmarSolicitudPedido(Pedido)
•Modificar pedido.
modificarPedido(Pedido,cantidad)
•Aprobar pedido.
aprobarPedido(Pedido)
•Rechazar pedido.
rechazarPedido(Pedido)
•Comunicar pedido
comunicarPedido (Pedido) (Elaborado)
•Registrar llegada de pedido
pedidosPendientesProveedor(Proveedor)
confirmarPedido(Pedido)

Paso 3. Diagrama de Clases.
En este apartado lo que haremos es construir el diagrama de clases a partir del modelo conceptual y los
diagramas de secuencia. En el diagrama de clases sólo mostramos aquellas clases que han aparecido en los
diagramas de secuencia. Mantendremos las asociaciones y atributos que existen en el modelo conceptual.
Incluiremos todos los métodos de los diagramas de secuencia y refinaremos las asociaciones: multiplicidad,
navegabilidad, agregación, etc.

CASO USO 02-Gestión de Pedidos

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

CASO USO 02-Gestión de Pedidos

Caricato da

Copyright:

Formati disponibili

UNP - Análisis de Sistemas Caso Práctico

SISTEMA DE GESTIÓN DE PEDIDOS

Modelado del Negocio

Modelado de Análisis y Diseño.

Ing. Esther Lizana Puelles 1

Paso 1. Identificar los agentes implicados en el proceso de negocio.

Los agentes implicados en el proceso de negocio son:

Paso 2. Establecer las acciones necesarias para realizar el proceso de negocio.

Paso 3. Construir un diagrama de actividades que represente el proceso de negocio.

Ing. Esther Lizana Puelles 2

Paso 4. Listar las actividades.

La lista de actividades que se realizan en el proceso de negocio son las siguientes:

Paso 5. Listar las Reglas de negocio.

Ing. Esther Lizana Puelles 3

En nuestro proceso de negocio podemos identificar tres.

Paso 1. Identificar Casos de uso.

Ing. Esther Lizana Puelles 4

Paso 2. Describir los casos de uso.

A continuación proponemos la plantilla de casos de uso que utilizaremos en este documento:

Caso de uso: nombre del caso de uso

Ing. Esther Lizana Puelles 5

CU1. Realizar pedido.

Caso de uso: Realizar pedido

Revisión con el cliente:

Teniendo en cuenta todo lo anterior, aparecen dos nuevos casos de uso:

Caso de uso: Realizar pedido manual extiende Realizar pedido

Ing. Esther Lizana Puelles 6

Caso de uso: Realizar pedido automático extiende Realizar pedido

CU2. Modificar pedido.

Caso de uso: Modificar pedido

Revisión con el cliente:

Caso de uso: Modificar pedido

CU3. Aprobar pedido.

Caso de uso: Aprobar pedido

Ing. Esther Lizana Puelles 7

Revisión con el cliente:

Caso de uso: Aprobar pedido

Caso de uso: Comunicar pedido

Caso de uso: Comunicar pedido por fax extiende Comunicar pedido

Ing. Esther Lizana Puelles 8

Caso de uso: Comunicar pedido por e-mail extiende Comunicar pedido

CU4. Registrar llegada de pedido.

Caso de uso: Registrar llegada de pedido

Revisión con el cliente:

Ing. Esther Lizana Puelles 9

Caso de uso: Aceptar pedido inesperado

Caso de uso: Rechazar pedido inesperado

Especificación relacionada con los pedidos conflictivos.

¿Quién debe realizar los pedidos conflictivos?

Ing. Esther Lizana Puelles 10

Los nuevos casos de uso que aparecen son los siguientes:

Caso de uso: Realizar pedido conflictivo

Caso de uso: Resolver conflicto

A continuación mostramos el caso de uso Tramitar Pedido especial a proveedor.

Caso de uso: Tramitar Pedido especial a proveedor

Ing. Esther Lizana Puelles 11

Priorización de Casos de uso

Paso 3. Crear el modelo conceptual.

Ing. Esther Lizana Puelles 12

 Solicitante de pedido - Solicita - Pedido

 Stock: cantidad, nivel mínimo, nivel normal.

Ing. Esther Lizana Puelles 13

Ing. Esther Lizana Puelles 14

MODELADO DE ANÁLISIS Y DISEÑO