Fundamentals of UML Diagrams

A diagram is the graphical presentation of a set of elements. UML has a lot of different diagrams. Make sure you can differentiate between different diagrams. Previous sections described UML diagrams; this section elaborates on them using examples.

Using the <> relationship

The "extends" notation extends the functionality of a use case to deal with errors or exceptions. "extends" relationship as shown in Figure 2.6 is being used when there is one use case that is similar to another but does a bit more. The relationship is drawn as a line with arrowhead pointing to the major use case.

The following is the essence of the "extends" relationship:

  • Capture the normal simple case first 
  • For every step in that use case, ask "What could go wrong here" and "How might this work out differently?" 
  • Plot all variations as extensions of the given use case.


Figure 2.6: An < > Relationship in a Use Case Diagram


Using the << include >> relationship 

"include" relationship as shown in Figure 2.7 can be used for making up a big use case from simpler ones.


Figure 2.7: An < > Relationship in a Use Case Diagram

Use Case diagrams serve a number of purposes. Use case diagrams provide: 

  • A graphical overview of system functionality. 
  • A bridge between developers and client/user. The notation is sufficiently simple to enable a non-user to understand and comment. 
  • A starting point for developing detailed requirements. 
  • A basis for developing design. 
  • Integration test cases.


Use Case Scenario 

A scenario is a description of a use case as a story. It is a story of one user's interaction with the system. It can be described in terms of:

  • The actors involved, and 
  • The steps to be taken in order to achieve the functionality described in the use case title. (Use cases are about functionality, so make sure the title reflects some functionality).

The steps involved usually take the form of the normal flow of events, followed by alternate flows and/or exception flows.

Example:

In an ATM banking system, a use case would be "Validate User". The steps involved in authenticating a user are described in scenarios. There will be a number of different scenarios for "Validate User", describing different situations that can arise.

Main (primary) flow of events for "validate user" use case could be: 

1. System prompts user for PIN number 

2. User enters PIN number via keypad. 

3. User commits PIN by pressing the Enter key. 

4. System then checks PIN to see if it is valid. 

5. If the PIN is valid, system acknowledges the entry. 

6. End of Use Case

Exception Flow of events 

1. System prompts user for PIN number 

2. User enters PIN number via keypad. 

3. User presses Cancel button to cancel transaction 

4. End of Use case. No changes made to user account.

By using scenarios, you are able to discover the objects that must collaborate to produce the results needed.