Robustness analysis

from Wikipedia, the free encyclopedia

The robustness analysis is a method in software engineering that can be used to examine different aspects of use cases. The existing text of the use case is analyzed and broken down into its components. As a result of the analysis, a robustness diagram is created, which basically corresponds to a simplified collaboration diagram .
By applying the analysis, a sanity check of the use case is primarily carried out. It is checked whether the text is coherent or irrational processes are possible. Other objects can also be found in the domain model that were not previously in focus. The robustness analysis also helps to identify missing alternative routes in the text of the use case, for example if a process fails.

The robustness analysis closes the gap between the pure analysis (use case - what should happen?) And the design (sequence diagram - how should it happen?). Consistent analysis of all use cases turns the original domain model into a class model. The body code of the application can in turn be generated automatically from a class model with suitable tools.

Components

The robustness diagrams consist of three different objects and the actor. The objects are connected with a simple line. However, there can also be an aggregation between the objects if, for example, the boundary object “Ok button” is part of the boundary object “Homepage”.

Boundary object

  • Form the interface between the actor and the system
  • Mostly represent buttons, input fields, but also entire dialogs or menus
  • Should it be easy to find application texts
  • Are nouns in the text of the use case

Entity object

  • Represent objects from the domain model
  • Often they correspond to database tables
  • The information held by the object survives the use case
  • Are nouns in the text of the use case

Control object

  • Are used as control objects between boundary and entity and are also called controllers
  • Can be found as verbs in the text of the use case
  • Controllers are often first used as placeholders, which are later replaced by methods of boundary / entity objects

Actor

  • The actor interacts with the system
  • As a rule, the actor represents a later end user

  • Boundary

  • Entity

  • Controller

  • Actor

regulate

There are four basic rules to keep in mind when creating the diagrams:

  1. Actors can only communicate with boundary objects
  2. Boundary objects can only communicate with actors and controllers
  3. Entity objects can only communicate with controllers
  4. Control objects can communicate with Boundary, Entity and other controllers, but not with actors

Guidelines

In general, one should not overdo the analysis and level of modeling. It should rather be understood as an integrated step after the creation of the use cases, rather than a stand-alone and independent analysis. In an article in the "software development magazine", Kendall Scott and Doug Rosenberg analyzed the most common / typical errors and described how to avoid them. Here are the most important as general guidelines for creating robustness diagrams:

  • You should update the static domain model according to the findings of the robustness analysis (enter newly found objects)
  • There should be a visual comparison between the description of the use cases and the robustness diagram (reading the text of the use cases and at the same time understanding them in the diagram)
  • You shouldn't build too many controller objects into the diagrams, the robustness analysis should be a quick "sanity check" for the use cases.
  • Alternative ways out of the application (e.g. in the event of an error) should also be shown

example

Example diagram

Here is an example of the use case in abbreviated form:
Name of the use case: Registration
Description: User logs on to the members' side
Participants involved: Member, web server, user database
Process steps (normal process):

  • The user enters the username and password on the login page and clicks the "Ok" button.
  • The system compares the entered data with those in the user database and delivers the member page.


When comparing text and diagram, the text should be read in parallel and the actions in the diagram should be followed. At this point it is also evident that no alternative has been modeled in the event that the user's data was not entered correctly.

Web links