Ejemplo Proceso de Negocio

Un proceso basado en UML para Sistemas de Información
Ejemplo de aplicación
Introducción.
Este documento explica cómo aplicar el proceso basado en UML, explicado en la asignatura
Arquitectura del Software, para desarrollar sistemas de información. Excepto las fases relativas
a la obtención y descripción de los procesos de negocio, el resto del documento es aplicable al
modelado orientado objetos de cualquier aplicación.
De la especificación de la práctica, podemos identificar varios procesos de negocio en la

organización: gestión inventario en comercios, gestión asociados, pedidos a proveedores, etc.
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. La identificación de buenos procesos de
negocio influye fundamentalmente en la organización de los diagramas UML, es decir, el tener
organizados en paquetes UML los elementos más relacionados. Por lo tanto, es una cuestión de
claridad en el modelado, que afectará a la consulta y posterior mantenimiento del modelo UML.
Modelado de Negocio.
Paso 1. Identificación de los procesos de negocio.
El primer paso para el modelado de una aplicación de negocio es la identificación de los

procesos de negocio. En este punto simplemente listamos los procesos que observamos en la
organización, para luego abordarlos uno a uno.
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.
Una vez identificados los procesos de negocio en este documento, elegimos uno de ellos,
pedidos a proveedor, para explicar las siguientes etapas. La descripción de este proceso de
negocio se encuentra localizada en la página 4, párrafo 3, de la especificación de la práctica.
...
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.
...
1
Paso 2. Identificar los usuarios, departamentos o elementos de la organización implicados
en el proceso de negocio.
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. Debemos destacar que
esto último no aparece en los requisitos, siendo necesario consultarlo con el cliente. Nunca
debemos inventar requisitos.
Por lo tanto, los agentes implicados en el proceso de negocio son:

 Solicitante pedido a proveedor.
 Responsable de abastecimiento.
 Operario.
 Proveedor.
Paso 3. 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:
El solicitante del pedido realiza un pedido en el sistema. 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. Éste tramitará el pedido y lo entregará en el
plazo establecido en la solicitud. Cuando llegue al centro de distribución, un operario se
encargará de registrar la llegada del pedido.
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 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.
2
Paso 4. 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.
Solicitante Pedido Responsable Abastecimiento Prov eedor Operador
Pedido
[sin aprobar]
Relizar Pedido Evaluar Pedido
¿Modificar?
Modificar
¿Aprobar? Tramitar Registrar

Pedido llegada pedido
Aprobar
Pedido
Pedido
Rechazar
[aprobado]
Pedido
En el diagrama anterior hemos mostrado sólo algunos flujos de datos. La herramienta Rational
Rose no permite definir flujos de datos. Así que los hemos definido como notas de diagrama.
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.
3
Paso 5. 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 estaba claro desde el principio, hemos decidido mostrarla 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 6. Listar las informaciones.
En este apartado debemos listar aquellas informaciones que fluyen a través del diagrama de
actividades. En nuestro ejemplo sólo hay un tipo de información: Pedido.
Estas informaciones nos serán de ayuda para construir el modelo conceptual. Es evidente que
existen más informaciones de las que aparecen en el diagrama de actividades. Toda la
información necesaria para realizar una acción no aparece en dicho diagrama. Sólo se muestran
las informaciones que intercambian las acciones.
Conviene documentar cada una de las informaciones encontradas. El objetivo es identificar los
atributos de la información. En este caso, un pedido tendrá como atributo un producto, una
cantidad y un proveedor. Como veremos más adelante, algunos de estos atributos se modelarán
en el diagrama conceptual como asociaciones.
Paso 7. 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:
- 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.
- Deberá evitarse la duplicidad de pedidos. No deben existir dos pedidos a proveedor para un
mismo producto.
- 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.
4
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. Un diagrama inicial de casos de uso para el
proceso de negocio quedaría de la siguiente manera:
Realizar pedido
Solicitante de
Pedido
Evaluar pedido
Modificar pedido
Responsable de
Abastecimiento
Aprobar pedido
Rechazar pedido
Registrar llegada de pedido

Operario
Como podemos apreciar, el diagrama que resulta es bastante sencillo. En general, no conviene
buscar relaciones extend o include entre los casos de usos, a no ser que resulten muy evidentes.
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. Estas
relaciones irán apareciendo conforme desarrollemos las plantillas de los casos de uso.
5
En general, hay que evitar una descomposición funcional 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. En
situaciones en las que dos o más casos de uso posean una etapa en común, podríamos considerar
su factorización.
Paso 2. Describir los casos de uso.
Para la descripción de los casos de uso podemos utilizar plantillas. UML no propone ningún
modelo de plantilla. 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.
 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?
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. En el modo automático no se podrá modificar la cantidad a pedir,
6
mientras que en el modo manual sí. 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

conseguir un nivel de stock 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

conseguir un nivel de stock normal, evitando la duplicidad de pedidos.
Precondiciones:
Pasos:
3. S: Calcular la cantidad a pedir
Variaciones:
Extensiones:
Cuestiones:
7
 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:
 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 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. 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.
8
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:
9
 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. Si llega
un pedido no esperado, habrá que notificarlo al responsable de abastecimiento. Este decidirá si
aceptarlo o no. Si lo acepta, deberá registrarse como una variación extraordinaria del stock. 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. 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. Se modelarían con una decisión que podría llevar a las siguientes acciones:
- Evaluar pedido inesperado, que se realizaría después de que el operario enviara la
notificación al responsable de abastecimiento.
- Estado final, que representaría una recepción correcta del pedido.
A su vez, la acción Evaluar pedido inesperado llevaría a dos nuevas acciones, dependiendo de
la decisión que tome el responsable de abastecimiento después de la evaluación del pedido.
Estas acciones serían Aceptar pedido inesperado y 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:
10
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: cdu Registrar variación extraordinaria de stock
Variaciones:
Extensiones:
Cuestiones:
En la plantilla anterior hemos introducido una relación include con el caso de uso Registrar
variación extraordinaria de stock. Este caso de uso aparece en otro proceso de negocio de la
organización.
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:
Cuestión.
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 la posible solicitud de pedido
a proveedor del producto en cuestión. Por ejemplo, un asociado ha solicitado 50 paquetes de
500 folios A4 al centro de distribución que deben ser servidos antes del viernes. La solicitud de
pedido llega el miércoles. En ese momento no existe stock suficiente para completar el pedido.
Supongamos que sólo existen 10 paquetes, que se ha rebasado el nivel mínimo de 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.
Surge la cuestión acerca de 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 él mismo el que realice un pedido especial para completar el pedido del asociado,
manteniendo la asociación entre ámbos.
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
11
Precondiciones:
1. El pedido del asociado debe estar en conflicto
Pasos:
1. A: Identifica el pedido de asociado en conflicto
Variaciones:
Extensiones:
Cuestiones:
Debemos destacar que la detección del pedido conflictivo queda fuera del caso de uso, incluso
del proceso de negocio, ya que estaría relacionado con el proceso de negocio Servir pedidos
comerciantes.
Caso de uso: Resolver conflicto

Objetivo: resolver el conflicto entre la restricción temporal 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 temporal del pedido del asociado.
Variaciones:
Extensiones:
Cuestiones:
Dentro del anterior caso de uso podemos ver la acción del sistema tramitar pedido especial a
proveedor. Esta acción aparecería como caso de uso en otro proceso de negocio. Es más
adecuado introducirlo como un caso de uso que esté relacionado con Resolver conflicto
mediante la relación include. Por lo tanto, modificaríamos el punto 2.1 de la sección Pasos de la
plantilla con “cdu Pedido especial a proveedor”, que indica una relación include.
También debemos destacar el paso 3.1 introducido para eliminar el conflicto, ya que éste se
origina por la restricción temporal que establece el asociado.
A continuación mostramos el caso de uso Pedido especial a proveedor.
Caso de uso: 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 Comuniar pedido
Variaciones:
Extensiones:
Cuestiones:
12
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:
13
Realizar pedido conflictivo
Centro de
Distribución
(f rom Logical View)
<<extend>>
Realizar pedido manual
<<extend>>
Solicitante de Realizar pedido
Pedido
Realizar pedido automático
Aceptar pedido inesperado Evaluar pedido
Modificar pedido
Rechazar pedido inesperado
Responsable de
Abastecimiento
Rechazar pedido
Resolver conflicto
Aprobar pedido <<extend>>

<<include>>
Comuniar pedido por fax
<<include>>
<<extend>>
Pedido especial a proveedor Comunicar pedido
Comunicar pedido por e-mail
Registrar llegada de pedido

Operario Proveedor
(f rom Logical View) (f rom Logical View)
14
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.
 Aprobar pedido.
 Rechazar pedido.
 Comunicar pedido por fax.
Además, simplificaremos varios casos de uso, especialmente el apartado de variaciones. Por

ejemplo, en el caso de uso Registrar llegada de pedido supondremos que el pedido llega
correctamente.
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 son 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 especificación de la práctica y de la

descripción de los casos de uso. Podemos utilizar el método de identificación de nombres y/o la
lista de categorías del libro de Larman.
Utilizando la técnica de identificación de nombres podemos encontrar los siguientes conceptos:

Solicitante de Pedido, Responsable de Abastecimiento, Operario, Proveedor, Comerciante,
Pedido, Pedido especial, Pedido asociado, Producto, Centro Distribución y Stock.
Podemos revisar la lista de categorías de Larman para ver si nos aparecen nuevos conceptos.
Aparecen Catálogo de productos (categoría catálogos) y Registro de pedidos (categoría registros
de negocio, trabajos, etc.)
Finalmente nos quedan los siguientes conceptos:
Solicitante de Pedido, Responsable de Abastecimiento, Operario, Proveedor, Comerciante,

Pedido, Pedido especial, Pedido de asociado, Producto, Centro Distribución, Stock, Catálogo de
productos y Registro de pedidos.
Veamos ahora las asociaciones. No es tan importante a este nivel del análisis el encontrar todas
las asociaciones. Identificaremos sólo las “necesita conocer”. 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
15
 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
 Catálogo - Contiene - Producto
 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.
16
Solicitante de
Pedido Operario
Responsable de Registra llegada
Abastecimiento Solicita
Sirve Proveedor
Aprueb a/Rechaza/Modifica
Asociado Pedido
Producto Pedido especial
cantidad
1 0..*
0..1
+pedidos 0..*
Contiene Está asociado
1
Registro de pedidos 1
Pedido de asociado Realiza
Asociado
1 cantidad
Posee 0..* 1
1 Posee
Centro de Distribución Catalogo
1 1 1 1
1
Posee
Contiene
1..*
Stock
1..*
cantidad
Producto
nivelMinimo
nivelNormal 1 1
1..*
Suministra
Tiene contrato
1
1..*
Proveedor
17
Modelado de Análisis y Diseño.
Paso 1. Diagramas de secuencia de 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.
 Realizar pedido manual.
: Sistema
: Solicitante de
Pedido
nuevoPedidoProveedor(Producto)
modificarPedidoProveedor(Pedido, Cantidad)
confirmarSolicitudPedido(Pedido)
: Sistema
: Responsable de
Abastecimiento
modificarPedido(Pedido, Cantidad)
18
 Aprobar pedido.
: Sistema
: Responsable de
Abastecimiento
aprobarPedido(Pedido)
 Rechazar pedido.
: Sistema
: Responsable de
Abastecimiento
rechazarPedido(Pedido)
 Comunicar pedido.
: Sistema
: Responsable de
Abastecimiento
comunicarPedido(Pedido)
19
: Sistema
: Responsable de
Abastecimiento
pedidosPendientesProveedor(Proveedor)
confirmarPedido(Pedido)
Paso 2. Diagramas de colaboración.
Este es el apartado más importante dentro del modelado orientado a objetos. El diseño de los
diagramas de colaboración influirá en las propiedades del software que desarrollemos:
reutilización, mantenimiento, etc.
A la hora de construir los diagramas de colaboración lo más importante es distribuir la

funcionalidad entre las clases. Para ello utilizaremos los patrones GRASP del libro de Larman,
los patrones de diseño del libro de Gamma, y en general, heurísticas del modelado orientado a
objetos, como las de Meyer y Riel.
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. El primero de ellos
trate de determinar el ámbito de la operación, es decir, determinar la responsabilidad de la
operación. 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.
Para describir el modo en el que la operación lleva a cabo sus responsabilidades y modifica el
estado del sistema utilizamos los diagramas de interacción. En el libro de Larman se recomienda
utilizar diagramas de colaboración. En general, son más compactos y ofrecen más información
(en la herramienta Rational Rose). Los diagramas de colaboración y secuencia son
semánticamente equivalentes. Así que podemos optar por mostrar las interacciones entre objetos
como diagramas de secuencia o de colaboración. En este documento hemos decidido definir las
interacciones utilizando diagramas de secuencia.
20
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
21
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.
: Centro de nuevoPedido : : Producto : Stock : Registro de

: Responsable de Distribución Pedido pedidos
Abastecimiento
"cantidad" es devuelta en
nuevoPedidoProveedor(Producto) los 3 métodos
create()
Establece el
estado "no setProducto(Producto)
confirmado
solicitante" calcularCantidad( )
cantidad := getCantidadMaximaPedido( )
getStockVacante( )
setCantidad(cantidad)
addPedido(nuevoPedido)
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.
Para distribuir la funcionalidad hemos aplicado los patrones GRASP. El patrón Creador nos
dice que el objeto encargado de crear una instancia de otra clase debe ser aquél que posea la
información necesaria para su inicialización. En este caso, la información para la inicialización
del objeto pedido es Producto, es decir, el producto al que está asociado. El que conoce esta
información es el Centro de Distribución. Por lo tanto, centro de distribución tiene la
responsabilidad de crear e inicializar el nuevo pedido.
22
Por otro lado, una de las responsabilidades de la operación que estamos definiendo es calcular la
cantidad apropiada del pedido. Según el patrón Experto, la responsabilidad debe estar asociada
a los objetos que conozcan esa información. El objeto que conoce la cantidad a pedir es Stock,
mientras que el objeto que conoce al objeto stock es Producto. Finalmente, quien conoce a
producto es Pedido. Esto último es discutible, ya que Centro de Distribución también conoce el
producto. Pero, aplicando el patrón de Bajo acoplamiento decidimos que centro de distribución
no conozca al objeto producto, ya que es pasado como un argumento de uno de sus métodos y lo
pasa como argumento de un mensaje a pedido, para crear la asociación, pero en ningún
momento depende de las operaciones de producto, es decir, un cambio en producto no afectaría
a centro de distribución. El mismo razonamiento podríamos aplicar a la relación entre pedido y
stock. Una opción podría haber sido que pedido pidiera el stock a producto y, él mismo, enviara
el mensaje para el cálculo de la cantidad máxima. Pero esto implicaría introducir una
acoplamiento innecesario entre clases (un pedido no tiene necesidad de saber que existe un
stock). Finalmente, el encargado de registrar el pedido es centro de distribución, ya que
representa al sistema y está asociado a Registro de Pedidos.
Finalmente, no se muestra explícitamente el establecimiento del estado (inicial) de pedido.

Hemos introducido una nota en el constructor para indicar que durante la inicialización del
objeto es cuando se establece el estado inicial, como parece lógico.
 modificarPedidoProveedor
Nombre: modificarPedidoProveedor(pedido: Pedido): boolean

Responsabilidades: modificar la cantidad de un pedido siempre que esté dentro de un margen
de variación expresado en tanto por ciento respecto al nivel normal y siempre que no sobrepase
el nivel máximo
Notas:
Excepciones:
Salidas:
Precondiciones:
- Estado del pedido = “esperando confirmación solicitante”
Postcondiciones:
- stock.nivelNormal - stock.nivelNormal * %variación <= pedido.cantidad
23
: Centro de : Pedido : Producto : Stock
: Solicitante de
Distribución
Pedido
modificarPedidoProveedor(Pedido, Cantidad) nivelNormal = cantidadMaxima
aceptable := nuevaCantidad(Cantidad,%Variacion)
cantidadMaxima := getCantidadMaximaStock( )
getNivelNormal( )
cantidadActual := getCantidadActual( )
Devuelve getCantidad( )
"aceptable"
[aceptable] setCantidad(Cantidad)
"aceptable" si:
cantidadActual + cantidad
<= cantidadMaxima - cantidadMaxima * %variación
24
El valor “%variación” es un atributo de la clase Centro de Distribución. Indica el porcentaje de
variación respecto al nivel normal en stock que permitimos cuando un operario modifica la
cantidad a pedir de un producto. Es una política del Centro de Distribución, así que lo adecuado
es que esté en esta clase. Entonces, la información necesaria para determinar si la modificación
es válida la posee la clase Centro de Distribución y la clase Stock, ya que la variación se expresa
en función del nivel normal. Aplicando el patrón Experto lo ideal es que la clase Pedido se
encargue del cálculo, ya que puede acceder al porcentaje de variación (lo toma como argumento
de un método) y a la cantidad máxima en stock (nivel normal) a través de Producto.
 confirmarSolicitudPedido
Nombre: confirmarSolicitudPedido(pedido: Pedido)

Responsabilidades: cambiar el estado de pedido como confirmado por el solicitante de pedido
Notas:
Excepciones:
Salidas:
Precondiciones:
- Estado del pedido = “esperando confirmación solicitante”
Postcondiciones:
- pedido.estado = “sin aprobar”
: Centro de : Pedido
: Solicitante de Distribución
Pedido
confirmarSolicitudPedido(Pedido)
confirmado( )
25
Caso de uso: Modificar pedido proveedor.
 modificarPedidoProveedor
Nombre: modificarPedidoProveedor(pedido: Pedido, nuevaCantidad: Integer): boolean

Responsabilidades: modificará la cantidad del pedido a proveedor, si no hace que el stock
sobrepase su nivel normal
Caso de uso: Modificar pedido proveedor
Notas:
Excepciones:
Salidas:
Precondiciones:
- Estado del pedido = “sin aprobar”
Postcondiciones:
- pedido.cantidad <= stock.nivelNormal

: Responsable de
Distribución
Abastecimiento
modificarPedidoProveedorRA(Pedido, Cantidad)
nuevaCantidad(Cantidad)
cantidadMaxima := getCantidadMaximaStock( )
getNivelNormal( )
cantidadActual := getCantidadActual( )
getCantidad( )
[aceptable] setCantidad(Cantidad)
"aceptable" si:
cantidadActual + cantidad <=
CantidadMaxima
Esta operación es muy parecida a modificarPedidoProveedor del caso de uso Realizar pedido
manual. La única diferencia está en la forma de determinar si la modificación es aceptable.
Hemos modificado el nombre de la operación, modificarPedidoProveedorRA, para que no se
confundiera con la anterior, ya que hemos decidido utilizar la misma clase controlador.
26
Caso de uso: Aprobar pedido.
 aprobarPedidoProveedor
Nombre: aprobarPedidoProveedor (pedido: Pedido)

Responsabilidades: cambiar el estado de pedido a “aprobado”
Notas:
Excepciones:
Salidas:
Precondiciones:
- Estado del pedido = “sin aprobar”
Postcondiciones:
- pedido.estado = “aprobado”
: Responsable de
Distribución
Abastecimiento
aprobarPedido(Pedido)
aprobado( )
 comunicarPedidoPorFax
Nombre: comunicarPedidoPorFax(pedido: Pedido)

Responsabilidades: enviar la orden de pedido al proveedor por fax
Notas:
Excepciones:
Salidas:
Precondiciones:
- Estado del pedido = “aprobado”
Postcondiciones:
- pedido.estado = “comunicado”
27
: Centro de : Pedido : Producto
: Responsable de : Proveedor
Distribución
Abastecimiento
comunicarPedidoPorFax(Pedido)
comunicarPorFax( )
getProveedor( )
comunicarPorFax(Pedido)
comunicado( )
Para llevar a cabo esta colaboración necesitamos una colaboración que informe al proveedor del
nuevo pedido. El problema está en determinar qué clase debe enviar la orden del envío al
proveedor. Según el patrón Experto, Producto es quien conoce a Proveedor y por tanto
deberíamos añadirle un nuevo método que fuera comunicarPorFax. Aunque esta solución
tendría bajo acoplamiento, comunicarPorFax es una operación que no está relacionada con el
resto de funcionalidad de la clase Producto, es decir, se pierde cohesión. Otra solución sería que
Pedido solicitara el Proveedor a Producto y se encargará de enviar el mensaje de
comunicarPorFax. Esta alternativa permite no romper la cohesión de la clase Producto, pero
introduce un nuevo acoplamiento Proveedor - Pedido. Nos quedamos con esta última solución
debido a que es natural que un pedido conozca a su proveedor.
Caso de uso: Rechazar pedido.
 rechazarPedido
Nombre: rechazarPedido(pedido: Pedido)

Responsabilidades: rechaza un pedido a proveedor, cambiando su estado a “rechazado”
Caso de uso: Rechazar pedido
Notas:
Excepciones:
Salidas:
Precondiciones:
- Estado de pedido = “sin aprobar”
Postcondiciones:
- pedido.estado = “rechazado”
28
: Responsable de
Distribución
Abastecimiento
rechazarPedido( )
rechazado( )
Caso de uso: Registrar llegada pedido proveedor.
 pedidosPendientesProveedor
Nombre: pedidosPendientesProveedor(Proveedor): Lista(Pedidos)

Responsabilidades: devuelve una lista con todos los pedidos que han sido comunicados al
proveedor
Caso de uso: Registrar llegada pedido proveedor
Notas:
Excepciones:
Salidas:
Precondiciones:
Postcondiciones:
29
: Centro de : Registro de p : Pedido : Producto
: Operario
Distribución pedidos
prov := getProveedor( )
getProveedor( )
comunicado := estaComunicado( )
Devuelve "p" si
"Proveedor = prov" y "comunicado"
 confirmarRecepcion
Nombre: confirmarRecepción (pedido: Pedido)

Responsabilidades: confirma la recepción del pedido y actualiza el stock del producto
Caso de uso: Registrar llegada pedido proveedor
Notas:
Excepciones:
Salidas:
Precondiciones:
- Estado del pedido = “comunicado”
Postcondiciones:
- stock.cantidad = stock.cantidad + pedido.cantidad
- pedido.estado = “finalizado”
30
Distribución
: Operario
confirmarRecepcion(Pedido)
finalizado( )
incrementarStock(cantidad)
incrementar(cantidad)
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 colaboración. En el diagrama de clases sólo mostramos aquellas
clases que han aparecido en los diagramas de colaboración. Mantendremos las asociaciones y
atributos que existen en el modelo conceptual. Incluiremos todos los métodos de los diagramas
de colaboración y refinaremos las asociaciones: multiplicidad, navegabilidad, agregación, etc.
31
Pedido
cantidad
setProducto()
calcularCantidad()
setCantidad()
Registro de pedidos nuevaCantidad()
Contiene +pedidos confirmado()
addPedido() nuevaCantidad()
pedidosPendientesProveedor() 1 0..* aprobado()
comunicarPorFax()
1 comunicado()
getProveedor()
estaComunicado()
Posee
finalizado()
rechazado()
0..*
1
Centro de Distribución
%Variacion : Integer
nuevoPedidoProveedor()
modificarPedidoProveedor()
confirmarSolicitudPedido()
modificarPedidoProveedorRA() Asociado
aprobarPedido()
comunicarPedidoPorFax()
pedidosPendientesProveedor()
confirmarRecepcion()
rechazarPedido()
1
Posee
1..*
1
Stock
cantidad Producto
nivelMinimo
nivelNormal getCantidadMaximaPedido()
getCantidadMaximaStock()
getStockVacante() 1 1 getProveedor()
getNivelNormal() incrementarStock()
incrementar() getCantidadActual()
getCantidad() 1..*
Suministra
Proveedor
numero fax
e-mail
comunicarPorFax()
32

Ejemplo Proceso de Negocio

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ejemplo Proceso de Negocio

Încărcat de

Drepturi de autor:

Formate disponibile

Un proceso basado en UML para Sistemas de Información

De la especificación de la práctica, podemos identificar varios procesos de negocio en la

Paso 1. Identificación de los procesos de negocio.

El primer paso para el modelado de una aplicación de negocio es la identificación de los

No debemos confundir un subsistema de información de la empresa con un proceso de negocio.

Por otro lado, el responsable de abastecimiento es el encargado de aprobar los pedidos y

Por lo tanto, los agentes implicados en el proceso de negocio son:

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

Un ejemplo de interacción entre roles podría ser:

El solicitante del pedido realiza un pedido en el sistema. El pedido es enviado al

Solicitante Pedido Responsable Abastecimiento Prov eedor Operador

Relizar Pedido Evaluar Pedido

¿Aprobar? Tramitar Registrar

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

Paso 6. Listar las informaciones.

Paso 7. Reglas de negocio.

Paso 1. Identificar Casos de uso.

Registrar llegada de pedido

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

Caso de uso: Realizar pedido

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

Caso de uso: Realizar pedido manual extiende Realizar pedido

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

Caso de uso: Modificar pedido

Caso de uso: Modificar pedido

Caso de uso: Aprobar pedido

Caso de uso: Aprobar pedido

Caso de uso: Comunicar pedido

Caso de uso: Comunicar pedido por fax extiende Comunicar pedido

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

Caso de uso: Registrar llegada de pedido

Las nuevas consideraciones provocan modificaciones en el diagrama de actividades del proceso

Caso de uso: Rechazar pedido inesperado

En la especificación del proceso de negocio se menciona que el responsable de abastecimiento

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 Pedido especial a proveedor.

Caso de uso: Pedido especial a proveedor

Finalmente nos queda el siguiente diagrama de casos de uso:

Aceptar pedido inesperado Evaluar pedido

Aprobar pedido <<extend>>

Pedido especial a proveedor Comunicar pedido

Comunicar pedido por e-mail

Registrar llegada de pedido

Además, simplificaremos varios casos de uso, especialmente el apartado de variaciones. Por

Es importante dar prioridades a los casos de uso y simplificarlos, si son excesivamente

Paso 3. Crear el Modelo Conceptual.

Comenzamos a construir el modelo conceptual a partir de la lista de informaciones que hemos

El siguiente paso es encontrar más conceptos a partir de la especificación de la práctica y de la

Utilizando la técnica de identificación de nombres podemos encontrar los siguientes conceptos:

Finalmente nos quedan los siguientes conceptos:

Solicitante de Pedido, Responsable de Abastecimiento, Operario, Proveedor, Comerciante,

 Solicitante de pedido - Solicita - Pedido

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

Paso 1. Diagramas de secuencia de sistema.

 Realizar pedido manual.

Paso 2. Diagramas de colaboración.

A la hora de construir los diagramas de colaboración lo más importante es distribuir la

Nombre: signatura de la operación

Caso de uso: Realizar pedido manual a proveedor.