Putting all the separate parts together the Order Entry prototype GUI would create one large form as follows:
The Sales Representative can spend the entire day using this one form and never have to move away from it.
Most of the information we used to create this GUI came from the use case Create New Order. However, there is at least one aspect of the GUI that follows from the sequence diagram. We have learnt that sequence diagrams place a temporal emphasis on an interaction. They give us the order in which events occur. Bearing that in mind, take another look at the sequence diagram that we created earlier. You can see that the user first selects a customer, then a category and then a product. Once the product is selected, the user enters the required quantity of that product. If you look at the form it is arranged in this order from the top down:
> First comes the customer information section
> Next, is a product category dropdown listbox
> Next, is a product dropdown listbox
> Finally, the order details and order information
This allows the user to easily perform the task without having to move all over the form. We are not only using our UML diagrams to keep a user within a single form to perform a single task, but we are also using our diagrams to arrange the sections on the form in the order the user is going to use them.
The flexibility of the Visual Basic user interface will allow there to be many different ways to enter information into the system and make requests for services to the system. Ideally, though, we want to find the most efficient flow of events and design our form around this scenario.
By the time we reach the logical design stage we have already put together a great deal of information on the corporation and their goals for the project. During our consensus meetings, we will have reviewed and rated all of the business processes related to the project, listing their good, neutral and poor qualities. From these ratings we should get a good idea of what is working and what is not working.
For example, if a company currently has a custom designed Visual Basic EXE application for entering orders, used by people in the order entry clerk role; we can look at the features of this system to help design an order entry web application for customers. If the forms for entering order information are rated as highly efficient and easy to use (see our last form!), we should consider using similar forms on the web page for the customer to enter the orders. If the order entry system has a highly efficient set of forms for reviewing product information, once again we could use this as a basis for the product pages on the web site. Of course, there may be some essential differences between the way we design a web page and the way we design a regular Visual Basic form, but it is a starting point. There is no reason to be constantly reinventing the wheel.
On the other hand, if the product forms received a very poor rating, and there is a general consensus that these forms are difficult to understand or use, then we need a new way of presenting product information for the web page. The users are a great source for recommendations on how to improve processes. By reviewing their reasons why a process is poor, we can often see how to improve it.
Was this article helpful?