Rosenberg and Stephen [ROSENBERG2007] introduced robustness analysis as a way for filling the gap between analysis (the what) and design (the how). From that point of view robustness analysis is a preliminary design when designers make assumptions on the design and start thinking of the possible technical solutions.

For supporting robustness analysis, they use robustness diagrams. This is a nonstandard diagram type in the manner that it is not described by the UML specification, however, it uses UML concepts. It is a specialized communication diagram that uses stereotyped objects. These stereotypes are defined in UML:

Figure 3.41. Elements of a robustness diagram

A robustness diagram is somewhat of a hybrid between a class diagram and an activity diagram. It visually represents a use case's behavior, showing both participating classes and software behavior. Nevertheless, it does not describe which class is responsible for which parts of the behavior. A robustness diagram is probably easier to read than an activity diagram since objects talks to each other. This flow of action is represented by a line between the two objects that are talking to each other.

It is a specialized communication diagram since not all object can talk to any other object. It is useful to think of boundary objects and entity objects as being nouns, and controllers as being verbs. Then the following rules apply in robustness diagrams:

These rules help to enforce a noun-verb-noun pattern in the text of use cases. This is useful as sequence diagrams have the very same nature: the objects are the nouns, and the messages that go between them are the verbs. So by following that pattern it will be easier to do the detailed design task later. Robustness analysis provides a sanity check for our use cases.

By revisiting our use cases, the first thing that we can find out that browsing and searching products need to be separated into two use cases since they have different operations. Here we only focus on searching which is the more complex of them.

Figure 3.42. Robustness diagram for Search product

Based on the robustness diagram we can rephrase the use case as follows:

Based on that we can also introduce a new class to our domain model: Catalog. The Catalog class is an abstraction of a container of all products. This is not to be confused with the inventory that has been mentioned earlier. The inventory contains information about the actually available pieces of products (those that are stocked) while catalog contains product metadata about each existing product (regardless of that there are any pieces of them on stock). Inventory was concerned as implemented by an external application that provides an interface to retrieve information on products in warehouses, however, catalog should be an integral part of this application since the whole lifecycle of a product is covered by our system's functionalities.

We have also created a roustness diagram for one of the most important use cases of the system, Place order.

Figure 3.43. Robustness diagram for Place order

The revised use case is the following.

For the rest of the use cases, the task of revisiting the use cases are left to the reader.

The ordering process can now illustrated with some sequence diagrams. Short explanations can be read below. These two diagrams reveal the differences found in the ordering phase if the ordering process is performed based on the selected bookshelf items or the shopping cart is used directly for th order.

Figure 3.44. Sequence diagram with bookshelf

On this diagram, eight elements can be found. Each element is placed one after an other in a horizontal manner. Each of them owns a lifeline (dashed vertical line) that indicates the existence of an element, i.e. the participation of an element in different interactions. The customer element as an actor calls the graphical user interface (GUI) element to establish a connection with the system. (S)He browse and search the list offered by the interface and, probably, views detailed information of certain products. The GUI sends a message to the product entity element to get appropriate information from it. After receiving information, the customer, with the help of the GUI, acquires the bookshelf through a message then (s)he can put selected products onto it. The bookshelf creates an item object that gains the appropriate product and wraps it. The item element returns to the bookshelf i.e. the bookshelf will hold the given product wrapped in an item object from now on. An item object is existing only during the period of time while a bookshelf is using it. Sequences from viewing product details to moving products as items to shelf, can be repeated many times (when the customer places not only one product on the shelf). Thereafter, the customer launches a request through the bookshelf to move certain (or all) items from it to the shopping cart. The customer can place an order through the shopping cart that calls the order entity. The system calculates total price for the order that, thereafter, can be confirmed by the customer who will be informed about this process through the graphical user interface.

Figure 3.45. Sequence diagram without bookshelf

This diagram is very similar to the previous one, it is almost the same except that the bookshelf object cannot be found here. The customer adds product items to the shopping cart directly, not through a bookshelf object. The adding steps can be repeated many times. Then, the customer places an order through the shopping cart. An explanation for remaining steps can be found in the previous section.