12.1 Actors, Use Cases & Subject Boundaries

12.1 Actors, Use Cases & Subject Boundaries

Quick Reference: SysML Use Case Diagrams (uc) capture the high-level functional capabilities and operational scope of a system from a black-box perspective. The Subject Boundary is a rectangular frame representing the system classifier under study. Use Cases (drawn as ellipses containing active verb phrases) reside strictly INSIDE the boundary, representing discrete services yielding observable value. Actors (human roles drawn as stick figures or external systems drawn as «actor» rectangles) reside strictly OUTSIDE the boundary.

---

Purpose and Role of Use Case Modeling in Systems Engineering

Use Case Diagrams (uc) belong to the Behavior Pillar of the Systems Modeling Language (SysML v1.2), reused directly from the Unified Modeling Language (UML 2 / UML4SysML). While structural diagrams (such as bdd and ibd) depict physical partitions, component hierarchies, and electrical or fluid interconnections, and detailed behavioral diagrams (such as act, stm, and sd) model step-by-step control flows, reactive states, and chronological message exchanges, Use Case Diagrams fulfill a distinct, high-level operational role:

1. Scoping System Boundaries: Defining unambiguously what functionality falls within the engineering responsibility of the development team versus what resides in the external operational environment.
2. Black-Box Capability Modeling: Specifying what services, functions, and operational goals the system delivers to external entities without exposing internal architectural components, algorithmic routines, software classes, or mechanical assemblies.
3. Stakeholder Context & Traceability: Establishing a clear bridge between high-level operational requirements, stakeholder needs, concept of operations (ConOps), and downstream behavioral and structural model elements. Downstream activities and sequence diagrams frequently elaborate, refine, or realize the operational behavior summarized by a use case.

In Model-Based Systems Engineering (MBSE), use case diagrams prevent two common engineering failure modes: scope creep (building functionality that no external stakeholder requires) and premature design commitment (constraining physical architecture before stakeholder capabilities and external interfaces are fully understood).

---

Diagram Frame and Context Element Syntax

Like all SysML diagrams, a Use Case Diagram must be enclosed within a rectangular outer frame border. The header in the top-left corner conforms strictly to the canonical SysML frame grammar:

uc [type] name [diagramName]

Common configurations include:

• uc [Package] OperationalCapabilities [System Use Cases] — When the diagram organizes use cases within an architectural or requirements package namespace.
• uc [Model] SpacecraftSystem [Black-Box Services] — When scoping system capabilities at the root model level.

The element named in the header represents the context namespace owning the diagram view. SysML 1.2 Annex A lists package as the element a use case diagram frame designates (a model is a kind of package). The system whose use cases are shown appears inside the frame as the subject rectangle, not in the heading.

---

The Subject Boundary: Defining the Operational Perimeter

The Subject (also referred to as the System Boundary) represents the system, subsystem, or component whose functional capabilities are being specified.

Graphical Notation and Rules

• Visual Representation: The subject is rendered as a large, bold rectangle placed on the diagram canvas.
• Subject Label: The classifier name of the subject is displayed in bold text near the top inside edge of the rectangle (e.g., «system» EnvironmentalMonitoringStation or AutomatedTollGate).
• Classifier Stereotypes: Modeler annotations may append standard or domain stereotypes, such as «system», «subsystem», or «component».
• The Strict Spatial Rule:
  • The subject's use cases go INSIDE the boundary: Every ellipse representing a capability the subject provides is drawn within the subject rectangle. (UML also allows use cases drawn with no subject rectangle at all, for example in a package-level overview.)
  • Actors go OUTSIDE the subject boundary: An actor is by definition external to the subject, so it is drawn outside the subject rectangle.

Exam Trap: Certification questions frequently present diagrams with an actor placed inside the subject boundary rectangle or a use case placed outside. An actor drawn inside the subject contradicts its definition as an external role, and a subject's use case drawn outside misstates the subject's scope.

Engineering Significance of the Boundary

The subject boundary establishes the formal contract between the engineering team and external stakeholders:

• Capabilities inside the boundary are funded, engineered, tested, and delivered by the system development organization.
• Elements outside the boundary represent external operational constraints, interfaces, human users, or legacy systems that the development organization must interface with, but does not construct or control.

---

Actors: Human Roles and External Systems

An Actor represents an entity external to the subject that interacts directly with the subject by stimulus, data exchange, command input, or service consumption.

Roles, Not Individual People

In SysML, an actor does not represent a specific individual person, job title, or physical employee (e.g., "Alice Smith" or "Senior Lead Technician"). Rather, an actor defines a coherent role played by an entity when interacting with the system under study. A single human user may play multiple actor roles (e.g., a person acting as SystemOperator during normal operations and as MaintenanceTechnician during diagnostic calibration). Conversely, multiple individuals can fulfill the identical actor role.

The Two Graphical Notations for Actors

SysML supports two distinct graphical symbols for actors:

1. Stick Figure Icon: The traditional human figure symbol. This is standard and intuitive for human operator roles (e.g., Pilot, Nurse, SystemAdministrator).
2. Rectangle with «actor» Keyword: A standard classifier rectangle enclosing the stereotype keyword «actor» and the actor name centered within. This notation is widely preferred in systems engineering when modeling non-human entities, such as:
   • External hardware devices (e.g., GPSReceiver, RadarAltimeter)
   • Legacy external software systems (e.g., CivilAviationDatabase, PaymentGateway)
   • Automated server infrastructure (e.g., WeatherForecastingService)
   • Environmental or physical entities (e.g., AtmosphericDisturbance, OceanCurrentSensor)

Primary vs. Secondary (Supporting) Actors

• Primary Actors: The external entity that initiates an interaction with the system to achieve a specific operational goal. The primary actor typically receives the primary observable value of the use case (e.g., Driver initiating ParkVehicle).
• Secondary (Supporting) Actors: External entities that the system contacts or relies upon to complete the use case requested by the primary actor. Secondary actors often provide auxiliary services, telemetry logging, or validation (e.g., PaymentProcessingNetwork assisting during PurchaseTicket).

---

Use Cases: Discrete Units of Observable Value

A Use Case represents a coherent, discrete unit of functional capability provided by the subject to one or more actors.

Graphical Notation and Naming Conventions

• Visual Representation: An ellipse (oval) containing the name of the use case centered inside.
• Naming Convention: Use case names are conventionally active verb phrases (a verb followed by a direct object or noun phrase). Examples include:
  • MonitorCabinPressure
  • ExecuteOrbitalCorrection
  • AuthenticateOperator
  • DispenseMedication

The Observable Result of Value

To be a valid use case in SysML, the capability must produce an observable result of measurable value for an actor. If a behavior executes entirely internally without producing any effect, data, or state change discernible to an external actor, it does not constitute a use case.

Anti-Patterns: What a Use Case is NOT

A frequent failure mode in systems modeling is confusing use cases with internal design elements:

• NOT Functional Decomposition: A use case diagram is not a flowchart or functional block diagram. Breaking a system down into tiny operational steps (e.g., ReadSensorByte, IncrementCounter, CloseRelay) degrades the model into an unreadable functional decomposition anti-pattern.
• NOT an Internal Algorithm: Purely computational routines (e.g., CalculateKalmanFilterGain or SortDataArray) are internal operations, typically modeled via Activity Diagrams (act) or Parametric Diagrams (par), not as standalone use cases.
• NOT a User Interface Action: Individual UI interactions (e.g., ClickOKButton, EnterPasswordString, ScrollWindow) are interface events, not system capabilities. The corresponding use case is AuthenticateOperator.

---

Use Case Elements Comparison Matrix

---

Worked Systems Engineering Scenario: Environmental Monitoring Station

Consider an autonomous, solar-powered Environmental Monitoring Station deployed in remote Arctic regions. The systems engineering team models its operational capabilities:

1. System Under Study (Subject Boundary): «system» ArcticMonitoringStation
2. External Actors (Outside Boundary):
   • Meteorologist (Human actor, stick figure) — Requests customized climate data reports.
   • WeatherSatellite (External system actor, «actor» box) — Receives automated daily telemetry transmissions.
   • AuxiliaryPowerGrid (External hardware actor, «actor» box) — Provides secondary line power during winter darkness.
   • MaintenanceTechnician (Human actor, stick figure) — Performs annual diagnostic calibrations.
3. System Capabilities (Use Cases Inside Boundary):
   • CollectAtmosphericReadings — Gathers temperature, humidity, and barometric pressure.
   • TransmitTelemetryArchive — Packages and transmits compressed telemetry to WeatherSatellite.
   • GenerateClimateReport — Formats and delivers statistical reports to Meteorologist.
   • CalibrateSensorArrays — Diagnostic routine executed by MaintenanceTechnician.
   • ManageSystemPower — Autonomous power distribution and battery heating control capability.

Notice how every use case provides an observable service, every actor interacts across the subject boundary, and internal sensor buses, microcontrollers, and wiring remain abstracted inside the black box.

---

Exam Pitfalls & Misconceptions