Robustness analysis

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

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

Robustness diagram for Search product

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

Use case IDUC001A
Use case nameSearch Products
DescriptionSearch for products based on some criteria.

The customer wants to browse among products or the customer would like to search for certain products.

PreconditionCustomer starts a web browser.
PostconditionSearch results meeting the criteria are displayed.
Normal flow
  1. Customer visits application home page.

  2. Customer clicks Search button.

  3. Search page is displayed by the system.

  4. Customer enters search criteria.

  5. The system validates the criteria provided.

  6. The system looks up the catalog to find the products that meet the criteria.

  7. Search results page is displayed with the products fulfilling the criteria.

Alternative flows

Refine Search Results

The following steps are added:

  1. Customer refines search results by providing additional criteria.

  2. Steps 5–7 are re-executed.


In Step 5, if search criteria is invalid or even missing then Step 3 (display search page) will be executed along with some hints on valid criteria.

In Step 6, if no products meet the criteria then Step 3 (display search page) will be executed along with providing the error message "Product not found".
Notes and issuesNone

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

Robustness diagram for Place order

The revised use case is the following.

Use case IDUC006A
Use case namePlace Order
DescriptionCustomer places an order to purchase certain products from the shop.
TriggerCustomer wants to order certain products from the shop.
PreconditionCustomer is logged in.
PostconditionThe system saves the new order.
Normal flow
  1. Customer visits the Shopping cart page.

  2. Customer clicks the Buy button.

  3. The system displays the Order details form where the required data to complete the order (name, phone number, email, shipping and billing addresses, payment method) needs to be provided.


    The system will retrieve information of the customer in order to populate a list of default values.

  4. Customer fills in data and submits Order details form by clicking the Confirm button.

  5. The system records the order.


    It retrieves shopping cart elements to add them to the order.

  6. The system displays the Order created page.

Alternative flowsNone
  1. The system cannot save the order due to a database failure.

  2. The customer can cancel the order at any time before confirming it.

IncludesManage Shopping Cart
Notes and issues
  1. The customer is unable to move items back into the shopping cart.

  2. If the order is cancelled, its items will also be lost.

  3. The system calculates and re-calculates the total price for the order according to the amount changes. This price includes not only the value of the price attribute of each item but also the discounts for certain products and for special customers.

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

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

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.