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:
«boundary». The interface between the system and the outside world. Boundary objects are typically screens or web pages (i.e., the presentation layer that the actor interacts with).
«entity». Entity objects are usually objects from the domain model.
«control». Control objects are the “glue” between boundary and entity objects.
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:
Nouns can talk to verbs (and vice versa).
Nouns can’t talk to other nouns.
Verbs can talk to other verbs.
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.
Based on the robustness diagram we can rephrase the use case as follows:
|Use case ID||UC001A|
|Use case name||Search Products|
|Description||Search for products based on some criteria.|
The customer wants to browse among products or the customer would like to search for certain products.
|Precondition||Customer starts a web browser.|
|Postcondition||Search results meeting the criteria are displayed.|
Refine Search Results
The following steps are added:
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 issues||None|
Based on that we can also introduce a new class to our domain model:
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.
The revised use case is the following.
|Use case ID||UC006A|
|Use case name||Place Order|
|Description||Customer places an order to purchase certain products from the shop.|
|Trigger||Customer wants to order certain products from the shop.|
|Precondition||Customer is logged in.|
|Postcondition||The system saves the new order.|
|Includes||Manage Shopping Cart|
|Notes and issues||
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.
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.
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.