CASO02-Gestión de Pedidos
CASO02-Gestión de Pedidos
CASO02-Gestión de Pedidos
CASO 2
SISTEMA DE GESTIÓN DE PEDIDOS
PROPUESTA
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 de Requisitos.
1. Identificar Casos de uso
2. Describir los casos de uso.
3. Crear el Modelo Conceptual.
1
Análisis de Sistemas con UML Caso Práctico
MODELADO 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.
2
Análisis de Sistemas con UML Caso Práctico
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.
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
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.
MODELADO DE REQUISITOS
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.
4
Análisis de Sistemas con UML Caso Práctico
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.
5
Análisis de Sistemas con UML Caso Práctico
Utilizando la plantilla anterior, pasamos a documentar cada uno de los casos de uso.
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.
6
Análisis de Sistemas con UML Caso Práctico
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.
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:
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.
8
Análisis de Sistemas con UML Caso Práctico
9
Análisis de Sistemas con UML Caso Práctico
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
Análisis de Sistemas con UML Caso Práctico
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.
11
Análisis de Sistemas con UML Caso Práctico
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
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.
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:
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
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.
2. Modificar pedido.
16
Análisis de Sistemas con UML Caso Práctico
3. Aprobar pedido.
4. Rechazar pedido.
5. Comunicar pedido
17
Análisis de Sistemas con UML Caso Práctico
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.
nuevoPedidoProveedor
18
Análisis de Sistemas con UML Caso Práctico
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.
comunicarPedidoPorFax
19
Análisis de Sistemas con UML Caso Práctico
20
Análisis de Sistemas con UML Caso Práctico
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