In Use Case Driven Object Modeling With UML Doug Rosenberg and Kendall Scott describe a technique called robustness analysis.  The basic idea is that you can analyze the steps of a use case to validate the business logic within it and to ensure that the terminology is consistent with other use cases that you have previously analyzed – in other words you can use them to ensure that your use cases are sufficiently robust to represent the usage requirements for the system you’re building. Another use is to identify potential objects or object responsibilities to support the logic called out in the use case, effectively acting as a bridge to other diagrams such UML sequence diagrams and UML class diagrams.

A robustness diagram is basically a simplified UML communication/collaboration diagram which uses the graphical symbols depicted in Figure 1.  As you can see robustness diagrams depict several types of concepts:

• Actors.  This is the same concept as actors on a UML use case diagram.

• Boundary elements.  These represent software elements such as screens, reports, HTML pages, or system interfaces that actors interact with.  Also called interface elements.

• Control elements. These serve as the glue between boundary elements and entity elements, implementing the logic required to manage the various elements and their interactions.  Also known as process elements or simply as controllers.  It is important to understand that you may decide to implement controllers within your design as something other than objects – many controllers are simple enough to be implemented as a method of an entity or boundary class for example. 

• Entity elements.  These are entity types that are typically found in your conceptual model, such as Student and Seminar. 

• Use cases (optional).  Because use cases can invoke other use cases you need to be able to depict this on your robustness diagrams.

Figure 1. Robustness diagram symbols.

Figure 2 shows a whiteboard sketch of a robustness diagram representing the logic contained in the Enroll in University system use case.  To create the sketch I merely followed the logic of the use case and applied the following heuristics:

• Add a boundary element for each major user interface element such as a screen or a report.  Although some very detailed use cases will describe how actors work with buttons and edit fields I prefer to stay at a higher level and not show these details.  I did however choose to show the Create Student Icon on the diagram although in hindsight this boundary class would be better labeled Desktop.  I chose not to update the diagram because I follow the AM practice Update Only When it Hurts and frankly it isn’t important enough to fix this minor issue.  These classes are likely to appear on your interface-flow diagrams if you choose to create them.

• Add a controller to manage the overall process of the scenario being modeled.  In Figure 2 this is the Enroll in University element.  As you can see it provides the glue which keeps the diagram together.  In your design this element could very likely be implemented as a class, as one or more operations, or via some sort of workflow engine if that is part of your overall architecture.

• Add a controller for each business rule.  This helps to make the business rules explicit on your diagram.  Some people will not model the business rules at all, keeping their diagrams simple, but as a result they miss very important information in their diagrams.  Try both ways and then choose the approach that works best for you.

• Add a controller for activities that involve several other elements.  An example of this is the Create Student element which interacts with a business rule as well as the Student entity. 

• Add an entity for each business concept.  The Student and Student Fee classes are examples of this.  These elements are likely to appear on your conceptual model if you chose to create one.

• Add a use case whenever one is included in the scenario.  I chose to depict the invocation of the Enroll in Seminar use case using standard UML notation for use cases.  Another option is to depict the use case as a controller although in my experience this isn’t as clear to project stakeholders.  Remember the AM principle Content is More Important Than Representation and do whatever is best for your situation.

Figure 2. Example robustness diagram.

By drawing a robustness diagram we quickly gain a sense for the work that we need to do to implement this use case because it helps to visualize the potential elements we’ll have to build.  The boundary elements will help to bridge your use cases to your user interface development and your legacy system analysis efforts.  Some of those classes are entity elements, things that should definitely appear on a conceptual model.  The controllers are much closer to design concepts, so robustness diagrams help to bridge to your design.

How do you keep robustness diagrams agile?  My experience is that the following AM practices are very relevant:

• Active stakeholder participation.  Robustness diagrams can be a very good technique, in some situations, to perform analysis with your stakeholders.  As you can see in Figure 2 robustness diagrams are very straightforward and easy to draw, making them an inclusive modeling technique.

• Discard temporary models.  Robustness diagrams are typically drawn on a whiteboard in order to analyze the logic of a use case.  Once the use case has been improved the robustness diagram will be kept around long enough to act as a bridge to the next development step, see below, then erased.

• Apply the right Artifacts.  Some modelers, including myself, will stop creating robustness diagrams when their stakeholders get used to making the logical jump from use cases to other development artifacts such as sequence diagrams.  In other words robustness diagrams are used to help train stakeholders to think abstractly and then abandoned as a technique once this goal is reached.  Other modelers will continue to use robustness diagrams because the models still add significant value to their overall efforts.     

What is next after robustness diagrams? Robustness diagrams often act as bridge from use cases to other models.  For example, it is quite common to create sequence diagrams which represent the detailed design logic required to support the use case.  It is also common to focus on the user interface for your system, perhaps via prototyping or better yet just getting right into the “real” coding, because robustness diagrams explicitly include boundary/interface elements.  Furthermore, because robustness diagrams depict major business entities it is quite common to use them as an input you’re your conceptual/domain modeling efforts.

Source

This artifact description is excerpted from Chapter 8 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.

Suggested Reading

• Artifacts for Agile Modeling: The UML and Beyond 
• Introduction to the Diagrams of UML 2
• Introduction to Object Orientation (OO) and UML
• Modeling Style Guidelines
• Why Extend the UML Beyond Object and Component Technology?

		This is the best reference that I know for robustness diagrams.  It goes into robustness analysis in great detail.
		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.
Successful Robustness Analysis		This is a great overview, written by Doug Rosenberg and Kendall Scott, of robustness analysis.
www.iconixsw.com		This site includes links to great articles as well as example models.

Translations

• Japanese

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer.  A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.