Introducing Use Case Diagrams

The Use Case diagram is a simple diagram that visually describes the users' goals with respect to the system or part of the system. This could be paraphrased to 'the value that the system provides to the Actors'. Use Case diagrams appear quite simplistic, with a small number of elements:

• Subject
• Actors
• Use Cases

These are connected by a series of relationships.

The Subject (boundary) provides a context for the definition and represents a system or part of a system; the Actors by definition lie outside the Subject and the Use Cases within. The Communication Path relationship by definition crosses the perimeter of the Subject as it connects an Actor with a Use Case. Again, the number of relationships is quite limited, but each has specific meaning in the diagram.

• Communication path
• Extend (also with Condition)
• Include
• Generalization

As with all SysML elements, there is both a graphical and textual aspect to the elements, and in the description of Use Cases there is typically more emphasis on the textual or narrative aspect.

Any number of Use Case diagrams can be created to represent the users' interaction with the system or part of a system. It is important to understand that Use Cases are intended to describe the value the system provides for its users and they are not intended to be broken down by functional decomposition. This is unquestionably the most common mistake made by novice modelers, resulting in the attenuation of the profound benefits that can be gained by this technique.

The Use Case model can be embellished by a mechanism called 'structuring the Use Case Model', which factors out repeating text, classifies Actors and Use Cases, and specifies extension points. This mechanism will be discussed later in this chapter. For more information see the SysML Use Case Models Help topic.

Creating a Use Case Diagram

A Use Case diagram can be created from a number of places in the User Interface by selecting:

• Design ribbon - Add  Diagram icon on the Diagram panel
• Browser window toolbar - New Diagram icon
• Browser window context menu - Add Diagram

We will use the Design ribbon to create a Use Case diagram. Firstly, select the location in the Browser window where you want the Use Case diagram to be located. As with all diagrams, this can be either a Package or an element, but it is common to insert Use Case diagrams into a Package. Once the Package location has been selected in the Browser window, select:

     Design > Diagram > Add Diagram

Selecting this option will open the New Diagram dialog, allowing you to name the diagram; the name initially defaults to the name of the Package or element that contains the diagram. With the SysML perspective chosen and the version of SysML selected, a list of diagrams will be displayed allowing you to choose the Use Case diagram. Click on the OK button to create a new Use Case diagram in the location selected in the Browser window. The Diagram View will be opened, allowing you to start adding elements and connectors that describe the value that the system will provide to its users. Enterprise Architect will also display the 'Use Case' pages of the Diagram Toolbox that contain the elements and relationships defined by the SysML specification to be applicable for constructing Use Case diagrams. Any number of other Toolbox pages can be opened, if required, in addition to the Common elements and Common Relationships Toolbox pages that will always be available.

The most important elements and connectors that are used with the Use Case diagram are:

Elements

• Actor - used to describe a role a user plays with respect to the system
• Use Case - used to describe the value a system provides to its users
• Boundary - used to show the scope of the systems (typically one per diagram)

Connectors

• Communication Path - used to connector Actors to Use Cases
• Generalize - used between two Actors or between two Use Cases
• Include - used between to Use Case to reuse scenario steps
• Extend - used to embellish a Use Case with extra detail

Elements can be added to the diagram by dragging-and-dropping them from the Toolbox onto the Diagram View. It is considered good practice to start with a Boundary element, which should be named appropriately to describe the system, sub-system or entity being modeled by the Use Case diagram. Leaving the name blank, or giving it a name that does not make it clear to the reader what system or part of a system is being modeled, can lead to misinterpretation of the diagram. With the Boundary added and appropriately sized in the diagram, Actors and Use Cases can be added - Actors positioned outside the Boundary and Use Cases inside. The next step is to add Communication Path relationships between Actors and Use Cases, thus defining the value that the Actors derive from the system.

Once a basic diagram has been created, and as knowledge of the domain and the system's behaviors are further revealed, it is possible to structure or embellish the diagram using the additional relationships of Include, Extend and Generalize. The newcomer is cautioned against using these relationships too liberally, and any attempt to use functional decomposition will attenuate the value of the Use Case model, which is intentionally broad in its description to allow stakeholders to get a 10,000 meter view of the services provided by the system, sub-system or entity being modeled.