Análisis de Sistemas con UML Caso Práctico

CASO 2
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.

DESARROLLO

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

1
Análisis de Sistemas con UML Caso Práctico

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.

2
Análisis de Sistemas con UML Caso Práctico

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.

3
Análisis de Sistemas con UML Caso Práctico

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:

4
Análisis de Sistemas con UML Caso Práctico

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

5
Análisis de Sistemas con UML Caso Práctico

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

Objetivo: realizar un pedido a proveedor con la cantidad necesaria del producto para
conseguir un nivel de stock normal, evitando la duplicidad de pedidos y permitiendo cierta
modificación
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. A: [Repetir de 0..n] Modificar la cantidad a pedir.
5. A: Confirmar el pedido.
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)

6
Análisis de Sistemas con UML Caso Práctico

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

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:
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?

Revisión con el cliente:

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
Actores: Responsable de abastecimiento
Precondiciones:
Pasos:
1. A: Indicar la nueva cantidad del pedido.
Variaciones:

7
Análisis de Sistemas con UML Caso Práctico

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
Actores: Responsable de abastecimiento
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?

Revisión con el cliente:

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.

Caso de uso: Aprobar pedido

Objetivo: aprobar un pedido a proveedor y comunicar al proveedor la solicitud del pedido
Actores: Responsable de abastecimiento
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

8
Análisis de Sistemas con UML Caso Práctico

Actores: Responsable de abastecimiento

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
Actores: Responsable de abastecimiento
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
Actores: Responsable de abastecimiento
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:

9
Análisis de Sistemas con UML Caso Práctico

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?

Revisión con el cliente:

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
Actores: Responsable de abastecimiento
Precondiciones:
Pasos:
1. A: Acepta el pedido inesperado.
2. S: Registrar variación extraordinaria de stock
Variaciones:
Extensiones:
Cuestiones:

10
Análisis de Sistemas con UML Caso Práctico

Caso de uso: Rechazar pedido inesperado

Objetivo: rechazar la llegada de un pedido inesperado llegado al centro de abastecimiento
Actores: Responsable 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.
Revisión con el cliente:
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:

11
Análisis de Sistemas con UML Caso Práctico

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
Actores: Responsable de abastecimiento
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:

12
Análisis de Sistemas con UML Caso Práctico

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,

13
Análisis de Sistemas con UML Caso Práctico

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.

14
Análisis de Sistemas con UML Caso Práctico

15
Análisis de Sistemas con UML Caso Práctico

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.

16
Análisis de Sistemas con UML Caso Práctico

3. Aprobar pedido.

4. Rechazar pedido.

5. Comunicar pedido

6. Registrar llegada de pedido

17
Análisis de Sistemas con UML Caso Práctico

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”

18
Análisis de Sistemas con UML Caso Práctico

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)

19
Análisis de Sistemas con UML Caso Práctico

Responsabilidades: enviar la orden de pedido al proveedor por fax

Tipo: Centro de Distribución
Caso de uso: Aprobar pedido
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)

20
Análisis de Sistemas con UML Caso Práctico

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.

21