12.2 Associations, Include, Extend & Generalization

12.2 Associations, Include, Extend & Generalization

Quick Reference: Use cases and actors interact through four primary relationships. Communication Associations (solid lines without arrowheads) link actors to use cases. «include» (dashed arrow) points FROM base TO included use case, enforcing mandatory execution. «extend» (dashed arrow) points FROM extension TO base use case (the opposite arrow direction!), representing optional execution at declared Extension Points. Generalization (solid line with hollow triangular arrowhead) models inheritance hierarchies between actors or between use cases.

---

Communication Associations: Connecting Actors to Use Cases

A Communication Association is the fundamental link between an actor and a use case. It signifies that the actor participates in the use case by exchanging signals, data, energy, or physical items with the system.

Syntax and Notational Rules

• Visual Representation: A solid, continuous line connecting an actor symbol to a use case ellipse.
• Arrowhead Rule: In standard SysML use case modeling, communication associations are drawn without arrowheads. This denotes bidirectional interaction: the actor initiates or sends input to the use case, and the use case returns status, results, or value to the actor.
• Multiplicity Adornments: Multiplicities may optionally be specified at either end of the association (e.g., 1 at the actor end and * or 1..* at the use case end), indicating how many concurrent instances of the actor or use case can participate simultaneously.

Crucial Rule & Exam Trap: A communication association line CANNOT connect two use cases together directly, nor can it connect two actors together directly. Connecting two use cases with a plain solid line is a severe syntax error frequently used as a distractor on certification exams. Relationships between use cases must exclusively utilize «include», «extend», or Generalization.

---

The «include» Relationship: Mandatory Shared Capability

The «include» relationship is a directed dependency between two use cases that factors out common, reusable behavior shared across multiple capabilities.

Syntax and Arrowhead Direction

• Visual Representation: A dashed line with an open stick arrowhead (--->).
• Stereotype Keyword: Labeled with the stereotype «include».
• Arrowhead Direction: The arrow points FROM the base use case TO the included use case:

BaseUseCase - - - «include» - - - > IncludedUseCase

Mandatory Execution Semantics

• Unconditional Invocation: Whenever the base use case executes, the included use case ALWAYS executes. Execution of the included behavior is mandatory for the base use case to complete successfully.
• Factoring Commonality: Used when multiple use cases share an identical behavioral sequence. Rather than duplicating the behavior across multiple use cases, the shared sequence is encapsulated into a separate use case and included by each base use case.
• Base Awareness: The base use case is explicitly designed with knowledge of the included use case and relies on its successful completion.

Real-World Example

Consider an aircraft avionics system where both ExecuteFlightPlan and PerformManualReroute require radio navigation verification. Both base use cases declare an «include» dependency pointing to the modular use case ValidateNavigationalWaypoints.

---

The «extend» Relationship: Optional and Exceptional Behavior

The «extend» relationship is a directed dependency that inserts optional, conditional, or exceptional behavior into a base use case.

Syntax and The "Opposite Arrow" Exam Trap

• Visual Representation: A dashed line with an open stick arrowhead (--->).
• Stereotype Keyword: Labeled with the stereotype «extend».
• Arrowhead Direction: The arrow points FROM the extension use case TO the base use case:

ExtensionUseCase - - - «extend» - - - > BaseUseCase

Critical Exam Trap: Modeler intuition frequently assumes the arrow should point from the base to the extension (since the base is being "extended"). SysML defines the exact opposite! The arrow originates at the extension use case and points toward the base use case. This semantic orientation signifies that the extension use case possesses the dependency knowledge of where and how it hooks into the base, whereas the base use case remains independent and decoupled from the extension.

Optionality and Conditional Execution

• Not Mandatory: Unlike an included use case, an extension use case does not execute automatically. It executes only when specific operational conditions occur, such as system faults, emergency overrides, or optional feature toggles.
• Base Decoupling: The base use case can execute to completion entirely on its own without the extension use case ever being triggered.

---

Extension Points: Anchoring Conditional Behavior

For an extension use case to know where within the base use case sequence its behavior should be inserted, the base use case must define one or more Extension Points.

Graphical Declaration of Extension Points

• Inside or directly below the base use case ellipse, a dedicated compartment is rendered with the heading extension points:.
• Each extension point is listed by an identifier name (e.g., extension points: ObstacleDetected, BatteryCritical).

          +----------------------------------+
         (          DeliverPayload            )
         (  --------------------------------  )
         (  extension points:                 )
         (    ObstacleDetected                )
          +----------------------------------+
                          ^
                          | «extend»
                          | condition: {obstacle_range < 2m}
          +----------------------------------+
         (       ExecuteObstacleEvasion       )
          +----------------------------------+

Condition Constraints and Notes

A constraint note or expression is typically attached to the «extend» dependency line, stating the guard condition (e.g., condition: {battery_charge < 15%}). When the base use case reaches the named extension point during runtime, the condition is evaluated. If true, the extension use case executes; if false, the base use case continues its normal sequence.

---

Generalization: Classifier Inheritance for Use Cases and Actors

SysML supports Generalization to model taxonomic inheritance hierarchies among use cases and among actors. In accordance with UML/SysML classifier semantics, generalization is drawn as a solid line with a hollow, closed triangular arrowhead pointing toward the general element (super-classifier).

1. Generalization Between Use Cases

• Notation: SpecializedUseCase ----▷ GeneralUseCase
• Semantics: The specialized use case inherits the operational intent, external actor associations, and extension/include dependencies of the general use case. The specialized use case provides a specific or alternative implementation of the general capability.
• Abstract vs. Concrete: The general use case is often abstract (rendered with its name in italics), meaning it establishes a common goal that is only instantiated through its concrete specializations.
• Example: AuthenticateOperator (general use case) specialized by AuthenticateViaBiometrics and AuthenticateViaSmartCard.

2. Generalization Between Actors

• Notation: SpecializedActor ----▷ GeneralActor
• Semantics: The specialized actor (sub-actor) inherits all communication associations connected to the general actor (super-actor). Any use case accessible to the general actor is automatically accessible to the specialized actor.
• Added Capabilities: In addition to inherited capabilities, the specialized actor can participate in additional exclusive use cases unavailable to the general actor.
• Example: In a mission control center, FlightDirector specializes MissionController. The FlightDirector inherits all routine monitoring capabilities of MissionController, but possesses exclusive communication associations to AuthorizeAbortSequence and OverrideSafetyProtocols.

---

Comparison Matrix: Use Case Relationships

---

Worked Systems Engineering Scenario: Autonomous Delivery Rover

Consider an Autonomous Delivery Rover operating in an urban pedestrian environment:

1. Base Capability with Mandatory Modular Inclusion:
   • The rover executes DeliverPayload. To complete this service, the rover must compute paths and navigate. DeliverPayload has an «include» dependency pointing to NavigateWaypoints.
2. Conditional Exception via Extension:
   • While navigating, a pedestrian may abruptly cross the rover's trajectory. DeliverPayload defines an extension point: extension points: ObstacleDetected.
   • The use case ExecuteObstacleEvasion has an «extend» dependency pointing to DeliverPayload, annotated with condition: {sensor_proximity < 1.5m}.
   • If no obstacle appears, ExecuteObstacleEvasion never executes; if an obstacle is detected, the evasion maneuver is inserted at the extension point.
3. Use Case Specialization:
   • The rover supports TransmitMissionLog. This capability is specialized into TransmitLocalWiFiLog and TransmitCellularLog via Generalization.
4. Actor Hierarchy:
   • FieldTechnician participates in PerformMaintenanceDiagnostic.
   • LeadFleetEngineer specializes FieldTechnician. The LeadFleetEngineer inherits the diagnostic capability and exclusively participates in FlashFirmwareImage.

---

Exam Pitfalls & Misconceptions