Functional Modeling: Use-Case and Activity Diagrams

Vocabulary practice cards covering use-case diagrams, activity diagrams, syntax elements, creation guidelines, and best practices.

Syntax of Use-case Diagrams

The standard UML notation elements used to construct use-case diagrams, including actors, use cases, subject boundaries, association relationships, include relationships, extend relationships, and generalization relationships.

Actor

A person or system that derives benefit from and is external to the subject. Depicted as a stick figure (default) or a rectangle with <> (alternative), labeled with its role, and placed outside the subject boundary.

Use Case

Represents a major piece of system functionality. Placed inside the system boundary and labeled with a descriptive verb-noun phrase.

Subject Boundary

Represents the scope of the subject (e.g., a system or an individual business process) and includes the name of the subject inside or on top.

Association Relationship

Links an actor with the use case(s) with which it interacts.

Include Relationship

Represents the inclusion of the functionality of one use case within another, with an arrow drawn from the base use case to the used use case.

Extend Relationship

Represents the extension of the use case to include optional behavior, with an arrow drawn from the extension use case to the base use case.

Generalization Relationship

Represents a specialized use case to a more generalized one, with an arrow drawn from the specialized use case to the base use case.

Syntax of Activity Diagrams

The complete graphical symbol set used in activity diagrams, including actions, activities, object nodes, control flows, object flows, initial nodes, final-activity nodes, final-flow nodes, decision nodes, merge nodes, fork nodes, join nodes, and swimlanes.

Action

A simple, nondecomposable piece of behavior in an activity diagram that is labeled by its name.

Activity

Used to represent a set of actions in an activity diagram and is labeled by its name.

Object Node

Used to represent an object connected to a set of object flows, labeled by its class name.

Control Flow

Shows the sequence of execution in an activity diagram.

Object Flow

Shows the flow of an object from one activity (or action) to another activity (or action).

Initial Node

Portrays the beginning of a set of actions or activities.

Final-activity Node

Used to stop all control flows and object flows in an activity (or action).

Final-flow Node

Used to stop a specific control flow or object flow.

Decision Node

Used to represent a test condition to ensure that the control flow or object flow only goes down one path, labeled with decision criteria.

Merge Node

Used to bring back together different decision paths that were created using a decision node.

Fork Node

Used to split behavior into a set of parallel or concurrent flows of activities (or actions).

Join Node

Used to bring back together a set of parallel or concurrent flows of activities (or actions).

Swimlane

Used to break up an activity diagram into rows and columns to assign individual activities (or actions) to responsible individuals or objects.

Appointment System Use-case Diagram

A sample use-case diagram for the Appointment System in the Patterson Store, displaying actors (Patient, Management, Doctor) associated with use cases (Manage Appointments, Produce Schedules, Record Availability).

Manage Appointments Activity Diagram

An activity diagram illustrating the workflow for the Manage Appointments use case, detailing paths for new vs old patient info, payment arrangements, and creating, canceling, or changing appointments.

Guidelines for Identifying Major Use Cases

A three-step process: 1. Review requirements definition, 2. Identify subject's boundaries, 3. Identify primary actors & goals.

Guidelines for Creating a Use-case Diagram

A four-step process: 1. Place and draw use cases, 2. Place and draw actors, 3. Draw subject boundary, 4. Add associations.

Guidelines for Creating an Activity Diagram

A three-step process: 1. Choose a business process, 2. Identify activities, 3. Identify control flows.

Business Process Modeling Best Practices

Key principles stating that activity diagrams are abstractions of reality, modeling should stay focused on one specific process, modeling must be performed in teams, and process modeling should be performed iteratively.