We know that the first thing the actor (in this case the Sales Representative) will have to do is make a request to the retrieve the record for a customer who has just phoned in to place an order. This request will be made to the Customers object via the Interface object. There is, as we know the possibility that the customer may not exist in our Customers object or that their details may need amending. This is shown on the diagram as a dotted line from the Customers object back to itself. If this is indeed the case, we know that the flow of events will be somewhat more complicated than shown in this diagram.
^s I mentioned earlier, the purpose of this diagram is to help us visualize the communication between our components. We could make a more detailed diagram showing all of these possibilities in full, but for the moment we should just be trying to get an overview of the process of making an order. Editing and creating a customer are not important to our overview of creating an order. For these reasons, we should leave these possibilities out of the diagram.
The Customers component then passes the CustomerlD onto the Orders object, as this object will need to know which customer this Orders belongs to. The Orders object will also need to create an OrderlD. Once the Customers object has returned the details about a particular customer, the Sales Representative requests the user interface to get products that belong to a certain category. The Interface passes this message along to the Products component, which returns the products to the user. Let's take a look and see how our sequence diagram is coming along:
The Sales Representative will then choose a particular product and add it to the Order Detail component. The Sales Representative can then select more products from this category or make another request for products from a different one. The Sales Representative will repeat this process until they have completed the Order that the customer desires. A dashed line at the Interface object shows this iterative process.
Once the Sales Representative has finished, they can tell the Interface to save the order. This request is passed to the Orders component and the Order Details components, which will then add this new record to the disconnected recordset and send the recordset to the middle tier. From here, it is passed to the database so that the database can be updated. As this final part of the operation is outside the realm of our client objects, it will not be shown in our diagram:
From this we can see that the first thing that happens is a customer will ring in to place an order. Then the Sales Representative will take their name and details. At this point there are three possible things that can be happening:
> The customer already exists and their details are correct.
> The customer is new and the Sales Representative will need to add them to the system.
> The customer's details have changed and the Sales Representative will need to amend them.
Since the customer information is only modified or added while adding an order, it would make sense to add and modify customers on the Order Entry form. Now a customer can be added or edited without interrupting the flow of the order by moving in and out of several forms. This part of the GUI could look like this:
Everything that the Sales Representative needs to carry out this initial part of her task is available to him or her on this form. There is no need to swap between forms to complete this part of the task.
The next part of the Order Entry task is to pick out the products that the customer wants and to add them to the order. This sub-task is quite distinct from taking the customer details and so should occupy a separate part of the form. It could look as follows:
Was this article helpful?