Understanding Use Case Modeling - Page 2

Sinan Si Alhir, http://sites.google.com/site/salhir/

Relationships

Association relationships between actor classes and use case classes are used to indicate that the actor classes participates and communicates with the system containing the use case classes. Association relationships are denoted as solid lines or paths. Arrowheads may be used to indicate who initiates communication in the interaction. If an arrowhead points to a use case, the actor at the other end of the association initiates the interaction with the system. If the arrowhead points to an actor, the system initiates the interaction with the actor at the other end of the association.

Figure 1 shows a project management system that provides functionality to manage projects. A project manager initiates this functionality and the system initiates the communication with the project database in providing this functionality.

Includes relationships from base use case classes to inclusion use case classes are used to indicate that the base use case classes will contain the inclusion use case classes; that is, the base use case will contain the inclusion use case. A base use case defines the location at which the inclusion use case is included. Includes relationships are denoted as dashed lines or paths with an open arrow-head pointing at the inclusion use case and are labeled with the <<include>> keyword (stereotype). The insertion of the inclusion use case involves the execution of the base use case up to the inclusion point, inserting and executing the inclusion use case, and then continuing with the execution of the base use case.

Figure 2 shows that a project manager may add projects and remove projects using the project management system. When removing projects, the functionality of finding a project is included into removing a project.

Figure 2

Extends relationships from extension use case classes to base use case classes are used to indicate that the base use case classes may be augmented by the extension use case classes; that is, the inclusion use case will augment the base use case if an extension condition is satisfied. A base use case defines the extension point. An extension use case defines the extension condition that must be satisfied in order to insert the extension use case into the base use case. The insertion of the extension use case involves the execution of the base use case up to the extension point, testing the extension condition and inserting and executing the extension use case if the condition is satisfied, and then continuing with the execution of the base use case. Extends relationships are denoted as dashed lines or paths with an open arrow-head pointing at the extension use case and are labeled with the extension condition in square brackets, the <<extend>> keyword (stereotype), and the extension point name in parentheses. Extension points are identified in a compartment labeled "Extension Points" in the base use case.

Figure 3 shows that a project manager may update projects using the project management system. When updating projects, a project manager may manage tasks if the project manager selects the task option, and a project manger may manage resource if the project manager selects the resource option.

Figure 3

Generalization relationships from specialization use case classes to generalized use cases classes are used to indicate the specialization use case classes are consistent with the generalized use case classes and may add additional information. A specialization use case may be used in place of a generalized use case and may use any portions of the interaction of the generalized use case. Generalization relationships are denoted as solid lines or paths with a hollow arrow-head pointing at the generalized use case.

Figure 4 shows that a project manager may publish a project schedule by sending e-mail to project team members using an e-mail system or by generating a web-site on a web-site host. In either case, there will be common functionality used from the generalized use case, for example: inputting project name, extracting the relevant project information form the project database, etc.

Figure 4

Generalization relationships from specialization actor classes to generalized actor classes are used to indicate the specialization actor classes are consistent with the generalized actor classes and may add additional information. A specialization actor may be used in place of a generalized actor and receives the characteristics of the generalized actor. Generalization relationships between actors are denoted similarly to generalization relationships between use cases.

Figure 4 shows that there are two types project mangers, full-time and part-time, and that there are two types of project database, relational database management systems (R-DBMS) and object oriented database management systems (OO-DBMS). Any type of project manager may publish a project schedule using any type of project database.

Page 1    Page 3    Back to the archive list