Maintain Customer Orders - Sequence Diagram

After you've finished the use case analysis and design for your system, you're ready to move on to construction. However, construction also includes some analysis and design which at the mimimum includes class and sequence diagrams. These diagrams are the tools you can use to translate the system actions in your use cases into responsibilities of business objects.

Here is a sequence diagram that models the Maintain Customer Orders use case (I've copied the use case text to the left of the diagram):

This diagram illustrates how the user (represented by the first object in the sequence) interacts with the user interface (represented by the UI object), and how in turn the user interface calls services of business objects to carry out the responsibilities of the system.

In the first part of the sequence, the user enters a customer id into the user interface. The user interface in turn calls a GetOrdersByCustomerID method of the **Orders **business object. Afterwards, the user interface displays the customer orders.

In the second part of the sequence, the customer selects to edit an order. The system responds by calling the Orders business object's GetOrderByOrderID method. Afterwards, the user interface displays the order header. Next, the user interface calls the GetOrderItemsByOrderID method of the OrderItem business object. Afterwards, the user interface displays the order items.

When creating this sequence diagram, how did we know to add an Orders object and an OrderItem object to carry out the system responsibilities specified in the use case? How did we know which methods to implement? This is where object modeling comes into play. I find this is one of the more difficult analysis and design skills you need to master. Again, my book Professional UML with Visual Studio .NET can help you climb this learning curve.

Note: It's considered good form to make your business object names singular rather than plural (for example, OrderItem rather than OrderItems). The reason I've created an object named Orders is because the word **Order **is a reserved keyword in SQL syntax, and we want to avoid any issues that might be associated with this!