On Using UML in the Systems Engineering Process for System

Requirements Development

Pete Ross, Shawn Simmons, Michael Crow

The Boeing Company

Integrated Defense Systems

1.0 Introduction

1.1 Need for Improved Methods of Implementing SE Process1.2 Where OOA, UML, and Related Tools Help

2.0 Comprehensive Requirements Analysis and Management Through Models & Databases

2.1 UML Use for Enhanced Definition & Communication of Requirements

2.2 Executable Modeling for Requirements & Design Analyses

3.0 Summary

1.1 Need for Improved Methods of Implementing SE Process

Large Scale Platforms ContainingHighly Integrated Systems

Many Platforms, Highly Integrated

Common Operating Picture And Information Available At All Echelons

Integrated Air Platforms

Integrated Ground Platforms

Highly Integrated Systems Engineering Processes are Needed to MeetThe Challenges Of Large Scale Integration Of System of Systems

Integrated Air And Ground Systems

Integrated Air And Ground Systems

Past• Performance Driven• Military Specs• Federated Systems• Focus on Delivered Quality

Present• Integrated Systems• Rapid Prototyping• COTS• Affordability Focus

Future• System-of-Systems Solutions For Network Centric Operations• Flexibility/Agility• “Time to Market” Focus• Commercial Practices and Products• MDA/ Effects Based Development• Quality at Each Step of Process

FA-18 C/D

The System Engineering Environment Has Changed

Future Concepts

DeltaLaunchVehicle

Systems Engineering Processes Must

Support FlexibilityThroughout

Development Process

Systems Engineering Processes Must

Support FlexibilityThroughout

Development Process

Operational Needs Are Continuously Changing

Systems Technologies are Constantly Evolving

Therefore RequirementsEvolve Continuously during A

Development Program

Operational Needs Are Continuously Changing

Systems Technologies are Constantly Evolving

Therefore RequirementsEvolve Continuously during A

Development Program

F-22

The Communication Challenge

• Capture and Integrate Analyses of Many Domain Experts to Properly Turn User Needs into System Requirements

۰ Increased emphasis on well organized and maintainable capture and analysis of user and inter-/ intra- system processes in a variety of situations

۰ For efficiency and clarity, need integrated processes, modeling languages, and tools

• Address Legacy Structured Analysis and Design Technique Shortfalls

۰ Tends to drive federated solutions۰ Low support for showing linkage of functional decomposition back to intended use

• Capture and Integrate Operator Intended Usage to Properly Turn User Needs into

System Requirements

۰ Need to keep customer in the loop well into the development process

۰ For efficiency and clarity, need to be able to effectively communicate with the intended users in a language that both they and the contractor team understand

Customer

Engineer

?Communicate

s in the language of a use domain

Communicates in the language

of a technology

domain

Command & Control Segment

The Systems Integration Challenge For SoS Architectures

Subsystem Level 4 Allocates to CSCI/HWCI

HWCI & CSCI Level 5 Allocates to HWC and CSC

Increased Focus of Integration at the Highest Level and ThereforeComplexity From Both the Operators and Developers Point of View

JTF/AOC Air Space

Air Vehicle Segment Radar Segment

eg. Cockpit, airframe, engine eg. Console, Comm gear Integrated Processor

Theater Command & Control Processes/Interactions

ICD

AV ICD:

Internal ICDs Internal ICDs

ICD.

Fu

nctio

nal &

Ph

ysical Arch

itectures

Weapon SystemLevel 2 (Concept)

Allocates to Segment

Land SeaForce StructureLevel 1(Context)

Requirements DetailAllocates to System

Major SubsystemLevel 3 (Logical)

Allocates to SubSys

Users Operational ViewSystem Developers View

DOD AF Intent is to Bridge these

Levels

DOD AF Intent is to Bridge these

Levels

Integration Has Been Focused At This Level Over Last Decade

Traditional SE Processes Have Not Been Proven To Be Efficient

Integration Has Been Focused At This Level Over Last Decade

Traditional SE Processes Have Not Been Proven To Be Efficient

Definition ofSystem Requirements

L1 OperationalFunction &

Performance

L1 OperationalFunction &

Performance

L2 System Function &

Performance

L2 System Function &

Performance

L3 SegmentFunction &

Performance

L3 SegmentFunction &

Performance

L4 Subsystem Function &

Performance

L4 Subsystem Function &

Performance

L5 CSCFunction &

Performance

L5 CSCFunction &

Performance

System

Segment

Subsystem

CSC

SDS9/10/02

BuildBuild

CSCI & HWCI

Allo

cate

req

uire

men

ts t

o:

Linear Time RepresentationOf Requirements Development

Processt

Test

Customer

SystemsEngineering

ProductEngineering

Test and Evaluation

IntegratedProcesses,Common Semantics

Visual Models,and Common

FormatPortable Data

Function & PerformanceAllocations

1.2 Where OOA, UML, and Related Tools Help

OOA/ UML Benefits

UML is a standardized language Which has Continued software and systems

engineering support

Captures Life Cycle Uses of System ByFormal Analysis of Multiple Use Cases

Commercial and defense industry

software development standard modeling

language

Activity

ClassAttributesOperations

State

represents operations in use

represents changes in attributes or operation activations

Elements used to model a real world object and its behavior

Integrates Abstract Physical & Behavioral ViewsUsing Object Oriented Analysis

What Are Object Oriented Analysis and Unified Modeling Language?

• OOA: Abstract modeling and analysis of real world objects behavioral interactions and architectural relationships

• Apply Content Decomposition Hierarchically to Aid in System Requirements Analysis

• OO is Used to Bound the Levels and Support Information Technology Based Descriptions of the System

• UML: UML captures the results of OOA• UML is an industry standard for conceptual/ visual modeling• Specified and maintained by non-profit Object Management Group (OMG)• UML is a language not a methodology

• Concepts, Semantics, Notation, Rules

Class Diagrams Use Case Diagrams Activity & State Diagrams Sequence Diagrams

Piloted Strike System & SoS Aggregations with System of System Classes in green

Air Operations Commander Mission Area Commander

Operation Commander

Combat Air Operations Group

11 0..n0..n

Operation Group

11

1..n1..n

Mission Commander

Small Diameter BombPSS Air Vehicle JDAM

Flight Package

1..n1..n

11

PSS Pilot

Piloted Strike System

0..n0..n11 0..n0..n

1..n1..n

11

Perform Final Pre-Flight Tests

Taxi Solo to Point

Enter Solo Flight Holding Pattern

Take Off Solo Air Vehicle

Enter Solo Landing Approach

Taxi Solo to Taxi Hold-Point

Taxi Solo to Take Off Hold-Point

<<extend>>

<<extend>>PSS Pilot

Air Traffic Controller

Land/ Taxi Solo Air Vehicle

<<include>>

<<include>>

Operation CommanderReceive Solo Mission Start

Clearance

Taxi/ Take Off Solo Air Vehicle

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

Mission plan completed in planning system, encrypted, and ready for transfer

Display menu for selecting method of transfer of mission plan to Air Vehicle

Radio mission plan to Air Vehicle

Transfer mission plan to data transfer cartridge

Choose appropriate mission plan transfer method

Carry data transfer cartridge to Air Vehicle

Put data transfer cartridge in Air Vehicle

Air Vehicle powered up, checked out and ready for mission plan

Radio receive mission plan

Receive data transfer cartridge

Request decryption key

Display confirmation of mission plan & pilot acceptance

Air Vehicle ready for taxi and operational use

See Mission Plan & Pilot Authentication Use Case

: PSS Air Vehicle : PSS Pilot : Planning System

: PSS Pilot : PSS Air Vehicle

: Airborne Tanker

: Refueling Specialist

Initiate Fuel Flow Through Fuel Boom

Display Fuel Level,Report Fuel Level

Visually Monitor Tanking Operation,Monitor Fuel Level

5: Radio Relay Fueling Anomaly Report(Verbal Anomaly Report : Data)

4: Report Fueling Anomaly Status(Anomaly Scene : View, Anomaly Fuel Level

Data : Data)

1: Flow Fuel to Air Vehicle(Initiate Fuel Flow :

Command)

3: Monitor Fueling Situation Display(Fuel Level : Data,

Fueling Operation Scene : View)

6: Audio Message Fueling Anomaly Report(Verbal Anomaly Report : Data) 7: Monitor for Fueling

Anomaly Reports(Verbal Anomaly Report : Data)

Display Fueling Progress,Display Interlock Locked Status

Seq's 3, 7, and 8 are concurrent2: Update Fueling Progress

Display(Fuel Level : Data)

8: Automatically Monitor for Fuel Level and Emergencies( )

Example Diagram Types

8 Diagram/View Types: Activity, Class, Collaboration, Component, Deployment, Sequence, State, Use Case

OOA/ UML Supports Decomposition of Use, Behavior, Objects, Data, and Interface Types

Form-Up for Coordinated Taxi

Taxi Coordinated to Point

Perform Final Pre-Flight Tests

Taxi to Point

Take Off Air Vehicle

Taxi/ Take Off for Specific Scenarios 1 & 2

Receive Coordinated Mission Start

Clearance

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

Taxi Coordinated to Take Off Hold-Point

<<extend>>

Taxi Coordinated to Taxi Hold-Point

<<extend>>

Mission Commander

Small Diameter BombAir Vehicle JDAM

11

Pilot

Piloted Strike System

0..n1 0..n0..n

1..n1..n

11

Flight PackageUse Decomposition

Content Decomposition

Captures Scenario Dependent Behavior

OOA/ UML Used to Capture Interface Behavior One Level at a Time

Completed Prepare System Pre-Mission Scenario Phase

Request Mission Start Clearance

Ready to Request Taxi Clearance

Receive Clearance

Completed Prepare System Pre-Mission Scenario Phase

Communicate Clearance

Communicate Request

Approve Mission Start Clearance

: Operation Commander : Air Vehicle : Pilot

Stimulus-Response Activity Modeling Between System and Externals,

Repeated at Next Level for Segment-Segment, Segment-Externals, and Similarly Through Remaining

Decomposition Levels

Provides Deterministic Means of How Far to Decompose Functionality at Each Level

Stimulus-Response Activity Modeling Between System and Externals,

Repeated at Next Level for Segment-Segment, Segment-Externals, and Similarly Through Remaining

Decomposition Levels

Provides Deterministic Means of How Far to Decompose Functionality at Each Level

UML Supporting Technologies

Process

ModelingStandard

EmergingTechnologies

OMGVision

ModelingMethodology

Model Driven Development Process

UMLtm (Unified Modeling Language)

MDAtm (Model Driven Architecture)

xUMLAction

SemanticsXMI

Profiles &Patterns

Design Tags

Code Templates

Object Modeling Methodology

OMG is working to provide a vision, framework, and definition at all levels ofsoftware and systems development on a non-proprietary basis

What is needed beyond OOA/ UML?

• Integration With Performance Requirements Analysis Tools & Processes• An adequate means to capture and manage performance requirements• Need visual models to capture timing and motion requirements• Need visual models for performance parameter decomposition/ allocation• Adequate functional architecture views for use as a framework for trade-

offs of physical architectures and performance allocation analyses• Adequate semantics for combined behavioral and performance

simulations• xUML provides some capability in this area

• Integration With Physical Modeling Tools & Processes• Adequate physical views for capturing and managing physical interfaces,

physical allocation analyses, and non-functional requirements

• Integration With Classical System Engineering Processes• Integrated cost, performance, schedule, risk models for use in trade-off

analyses

2.0 Comprehensive Requirements Analysis and Management Through Models & Databases

2.1 UML Use for Enhanced Definition & Communication of Requirements

2.2 Executable Modeling for Requirements and Design Analyses

2.1 UML Used for Enhanced Definition & Communication of Requirements

The Coordination Challenge

SystemsEngineering

ProductEngineering

Test and Evaluation

CustomerStakeholders

0 kft

Down Range

Cross RangeAirborne TankerPSS Air Vehicle

0 km

+/- 30 deg Max Angle to Start Approach

Use Case Connect for In-Flight Refueling, Thread CFIFR-1

Notes and Justifications: +/- 30 deg approach angle driven by viewing angle available to Fueling Specialist through cameras, and he needs to visually confirm approach and approach rate

These graphics are for illustration purposes only and do not represent any real vehicle requirements.

< Max Start Distance

0 kft

Down Range

Cross RangeAirborne TankerAirborne TankerPSS Air VehiclePSS Air Vehicle

0 km

+/- 30 deg Max Angle to Start Approach

Use Case Connect for In-Flight Refueling, Thread CFIFR-1

Notes and Justifications: +/- 30 deg approach angle driven by viewing angle available to Fueling Specialist through cameras, and he needs to visually confirm approach and approach rate

These graphics are for illustration purposes only and do not represent any real vehicle requirements.

< Max Start Distance

Use C

ase

Threa

d Num

ber in

Us

e Cas

e

Threa

d Typ

e

Threa

d Crite

ria

Type

Threa

d Crite

ria

Desc

riptio

n

Threa

d Pe

rform

ance

Type

s

Refer

ence

Grap

h, Ta

ble, o

r Doc

umen

t

Perfo

rman

ce V

alue

Type

Perfo

rman

ce V

alue

1 Perfo

rman

ce V

alue

2 Perfo

rman

ce V

alue

Units

Perfo

rman

ce

Reqm

t Typ

e

Justi

ficati

on

Posit

ion of

Acti

vity

in Th

read

Activ

ity N

ame

Clas

s Nam

e

Connect for In-Flight Refueling 1 C2 Start

PSS Pilot has visually acquired Airborne Tanker and received radio clearance from Refueling Specialist to come in for tanking.

Time to Complete Maximum 5 min Goal

Human concentration fatigue start threshold

Beginning

Control PSS Air Vehicle to Connect to Fuel Boom PSS Pilot

End

Fueling boom is interlocked to PSS Air Vehicle. Confirmation from PSS Air Vehicle that interlock is complete. Fuel levels in PSS Air Vehicle are displayed to both PSS Pilot and Refueling Specialist.

Intermediate Time

Constraints

Connect for In-Flight Refueling -1

Concurrent Timing Diagram See diagram notes

Beginning

Control Fuel Boom to Support Connection to Air Vehicle

Refueling Specialist

Air Vehicle - Tanker Start Separation Maximum 10 km Notional

Existing standard stand-off distance

prior to start of tanking operations End

Display Interlock & Fuel Status

PSS Air Vehicle

Tanker SpeedMin and

Max 250 350 nmph Firm

Existing tanker dispensing safety

limits EndDisplay Interlock Locked Status

Airborne Tanker

Tanker Altitude

Min and Max 2 20 kft Firm

Existing tanker dispensing safety

limits EndDisplay Fueling Progress

Airborne Tanker

Intermediate Movement Constraints

Connect for In-Flight Refueling -1 Movement

Constraint Diagram See diagram notes

Start In-Flight Refueling 1 C2 Start

Fueling boom is interlocked to PSS Air Vehicle. Confirmation from PSS Air Vehicle that interlock is complete. Fuel levels in PSS Air Vehicle are displayed to Refueling Specialist.

Beginning

Initiate Fuel Flow Through Fuel Boom

Refueling Specialist

EndFuel is flowing to PSS Air Vehicle. Updated fuel level dispalyed to Refueling Specialist. End Update Fueling Progress

Airborne Tanker

Develop System

Manufacture System

Test System

Distribute System

Operationally Use System

Support System

Train with System

Dispose of System

Program Start or Modification Start

Ready for Operational

Test

Storage Assigned

Disposal Assigned

Modification Assigned

Manufacturing Acceptance Tests Passed

Significant Redesign Required

Operational Tests Passed

Support Required

Operational Mission or New Base Assigned

Training Mission Assigned

New Base, Modification, or Disposal

Assigned

Disposal Assigned

Support Required

Disposal Assigned

Function X

Time

Map Best Models & Data Constructs to an Integrated SE ProcessUse UML Model as Focal Point to Tie Together Engineering ProductsMap Best Models & Data Constructs to an Integrated SE Process

Use UML Model as Focal Point to Tie Together Engineering Products

Integrated Processes, Common Semantics Visual Models, and Common Format Portable Data

Matrices/Databases Graphs DrawingsSimulations Block

Diagrams

UML ModelContext Diagrams, Process Flows, Use Descriptions, Item

Exchanges, Candidate Technology &Solution Objects Classes

Multi-Discipline Participation in Use Case DrivenArchitecture Development & Design

System Con Ops,Safety, Security

Measures ofEffectivenessMeasures ofEffectiveness

System Effectiveness,Reliability

ArchitecturallySignificant

MissionScenarios

Interoperability

Architecturally SignificantMission Scenarios

Identify Functional Interaction of System with

External Participants And Use of IERs

Architecturally SignificantMission Scenarios

Identify Functional Interaction of System with

External Participants And Use of IERs

AbstractUse Case

“Operate System”

PerformanceRequirements

Database

Nominal Use ThreadsContingency Threads

Views Need to Convey All Aspects of Each LevelOf The Architecture To All Stakeholders

User/Customer

ProductTeam

Cubes Represent Engineering Data & Architecture Products

The Products Developed are Organized Based on the Zachman FrameworkThe goal of Using a Framework is to Ensure an Architecturally Complete Description

L3 L4 L5

L2

L1

L1 L2

PeopleTime

FunctionData

Network

Functional Analysis

Synthesis

Requirements Analysis

Motivation

Integration & Test TeamSpecializedViews Like

SecurityAre Created

For Each Level From Data

Across the Rows

Engineering Products Provide Forum and Canvas for Product Definition and Refinement

ArchitecturallySignificant

MissionScenarios

Functional Architecture

Modes

Activities

Use Cases(for all life cycle phases)

Capabilities

States

Performance

Threads

External Systems

Physical Architecture

Measures of Effectiveness

Database

Views

Product RelationshipsProvide LinkageTo Intended UseScenarios

Construction of The Functional ArchitectureAnd Allocated To The Physical Architecture

Class 4Attributes

Operations

Operation p ()Operation q ()Operation r ()

Attribute xAttribute y

State Diagram

Class Association (roles) Relationships

Object BObject A Object C

Activity 1

Activity 2

Activity 3

Activity 4

Activity 5

State I State II

State III

State IV

Superstate A

StateDiagram

Component 1

Component 2

Node A

Component 3

Component 4

Node B

Deployment Diagram

ClassDiagram

Class 1Attribute xAttribute yProcess I ( )Process j ( )

Class 2Attribute xAttribute zProcess k ( )Process n ( )

* 1

Class 4Attribute wAttribute z

Class 5* 0..3

Class 3Attribute qAttribute rProcess o ( )Process p ( )

Class Diagram

Integrated Process & Environment for Deriving Behavioral Requirements

Use Driven and Methodical Requirements Derivation

Functional Architecture

Life Cycle Phases

Modes

Activities

Use Cases

Capabilities

States

Performance

Threads

ExternalSystems

Safety, Health, Quality,

Security, Survivability,

Concepts

Use Scenario Script Driven Verification Using Logic and Timing Simulations

StateModel

PerformanceModel

Interactive Simulation

UMLUML

MatrixMatrixIDEFIDEF

Linking performance with functional architecture to validateArchitecture meets Measures of Effectiveness is key

Performance Analysis

Integrate Commercially Available Tools

TradeStudies

PerformanceAnalysisModeling

RiskToolChange

Management

UML Tool

Requirements Management

Database

Best Of BreedToolsets ShouldBe Combined to

Achieve MaximumIntegration Across

System EngineeringTasks

System EngineeringToolsets

Should Be ChosenTo Be Synergistic

With SoftwareEngineeringEnvironment

2.2 Executable Modeling for Requirements and Design Analyses

Where Executable Modeling Fits In

• To Meet System Analyses Needs:• Capacity (bandwidth)• Security• Fault Tolerance• Interoperability• Interference• Operator Awareness• Control Logic, Timing, Accuracy• Safety (Maintain Physical Separation)• Timelines and accuracies required to

Carry out Mission Objectives

• Supports SE Information Needs:– Critical Function Partitioning– Data for Systems Engineering Trade Studies and “what if” analysis.– Data to Verify requirements and architecture completeness.– Data to Verify interface definition.

In the Development Process

Functional Analysis / Allocation

Verification Loop

Design Loop

Requirements Loop

Requirements AnalysisSystem Analysis

Analysis &Control Loop

Iteration Loop Synthesis

Relationship of Executable Modeling toVerification and Validation

L1 Function & Performance L1 Function & Performance

L2 System Function &

Performance

L2 System Function &

Performance

L3 Segment Function &

Performance

L3 Segment Function &

Performance

L4 Subsystem Function &

Performance

L4 Subsystem Function &

Performance

Op Eval System

Exercise

Op Eval System

Exercise

Segment TestSegment Test

Subsystem Test

Subsystem Test

CSCI & HWCI Test

CSCI & HWCI Test

L5 CSCI Function &

Performance

L5 CSCI Function &

Performance CSC TestCSC Test

System

Segment

Subsystem

CSC

SDS9/10/02

BuildBuild

CSCI & HWCI

Allo

cate

req

uire

men

ts t

o:

Executable Modeling

The Role of Executable Modeling is to Verify the Requirements for Consistency And Validate that the requirements meet the requirements from the level aboveThe Role of Executable Modeling is to Verify the Requirements for Consistency And Validate that the requirements meet the requirements from the level above

Function & PerformanceAllocations

Validation

Verification

V&V TestingIs performed

On the As-built,As coded system

With Hardware In the Loop

Executable Modeling is performedUsing the analysis model

of the “To be built” System

AV ClassOperation 1Operation 2Operation 3

Transitioning From FunctionalModeling to Executable Modeling

Operation n……

Object BObject A Object C

Activity 1

Activity 2

Activity 3

Activity 4

Activity 5

Bring together Physical, Functional, Data to EvaluateLogical Consistency & Performance

Bring together Physical, Functional, Data to EvaluateLogical Consistency & Performance

State I State II

State III

State IV

Superstate A

StateDiagram

Object BObject A Object C

Activity 1

Activity 2

Activity 3

Activity 4

Activity 5

Object BObject A Object C

Activity 1

Activity 2

Activity 3

Activity 4

Activity 5

Object BObject A Object C

Activity 1

Activity 2

Activity 3

Activity 4

Activity 5

A State ModelIs Developed for

Each Class

Tools Should Be Chosen to Best Fit The Needs of the Purpose of the Analysis

System Analysis & Tool Suitability

Logical: SegmentLogical: Segment

Context Level Architecture Analysis• Concept Modeled As A “Black Box”• Model of Domain Elements as Sources And Sinks

Concept Level Architecture Analysis• Segment Elements Modeled As “Black Boxes”• Domain Elements Modeled as Sources And Sinks

Logical Level Architecture Analysis• Physical Elements Modeled As “Black Boxes”• Concept Elements Modeled as Sources And Sinks

Concept: Weapon SystemConcept: Weapon System

Context: Force StructureContext: Force Structure

Capacity (bandwidth)Latency (delays)

SecurityFault ToleranceInteroperability

InterferenceOperator Awareness

Communications Analysis

Using UML In TheSystem Engineering Process

• Best Solution for Behavioral Requirements Development• Strongly and clearly driven by concepts of use and documented knowledge of required interfaces with

other systems. • Use case based approach fosters multi-discipline participation

• Provides Appropriate (Use Oriented) Focal Point to Organize and View Other Model Artifacts

• Provides Clear Traceability of Derived Behavioral Requirements• Saves $$$ for changes and supports spiral development

• Provides Strong Foundation for Engineering & Design Processes Automation• Large industry investment and support from Software Engineering

Design Of Highly Integrated Systems Require Integrated SE ProcessesAdoption of a UML based Object Oriented Architecture Centric SE Process

That Uses Modeling and Simulation As Its Core, Meets That Need

A Disciplined Architecture Centric Systems Engineering ApproachWill be Required to Provide Interoperable C4ISR Systems to Meet

The Challenges of Information Dominance

A Disciplined Architecture Centric Systems Engineering ApproachWill be Required to Provide Interoperable C4ISR Systems to Meet

The Challenges of Information Dominance