Application of
UML in Aegis
Open Architecture
Andrew.J.Winkler@lmco.com
November, 2002
Naval Electronics & Surveillance Systems - Surface Systems
Moorestown, New Jersey
Aegis Combat System
“The shield of the fleet…”
 A Highly Integrated Total Ship Combat System
 Aegis Weapon System (AWS) Provides Core Sensor, Weapon and C2 Capability
 Long-Standing Development/Production Program
 CG-47 Ticonderoga Class Cruisers Deployed
 DDG-51 Arleigh Burke Class Destroyers Ongoing
 Evolving Requirements Drive Continual Improvements via Baseline Upgrade Program
 Aegis Open Architecture (Baseline 7 Phase II)
 Flexible, Component-Based SW Architecture
 Object-Oriented Methodologies and Design Patterns
 Scalable “Bedrock” for Future Functionality and Performance Improvements
 Goals of Open Architecture
 Improve Extensibility for Introducing New




Warfighting Capabilities (Threat Evolution)
Reduce Development Time
Reduce Maintenance Cost
Affordably Manage COTS Obsolescence
Improve Usability Through Human-System
Integration (HSI)
OMG UML for SE
AJW -2- 11/19/02
Open Architecture Overview
Approach and Goals
NAVSSI
JMCIS
HF, UHF,
SATCOM
EXCOM
Baseline 7 Phase I
Aegis Combat System
JTT
SGS
ADS
MARK 6
ICOM/
ON-201
-
Sensors and Comms
Incoming Interface
LINK 4
LINK 11
LINK 16
WCS/FCS
C&D
C2P
(MODEL 5)
NETWORK
INTERFACES
VIA ALIS
EWS
RADARS
(2)
FCS
CEC
IFF
GWS
SPY
VLA
SM-2
TLAM
SM-2 IVA
Weapon and CM
Outgoing Interface
BFTT
UWS
SVTT
SVTT
LSE
LSE
SPS-67
AN/SPY -1
LSTP
VLS
ACTS
REHOST
SPS-73
TWS
ORTS
UPDGRADE
EWS
SQQ-89
LSE
Control
COUNTER
MEASURES
RMS
AOA Approach
• Perform Top-Down Analysis with “Clean
Sheet” Flexibility
• Re-Examine AWS Partitioning
• Develop Flexible, Component-Based
Software Architecture
• Employ OO Methodologies/Patterns
• Minimize Impact to Enclosures/Interconnect
OMG UML for SE
AOA Goals
• Improve Extensibility for Introducing New
Warfighting Capabilities (Threat Evolution)
• Reduce Development Time
• Reduce Maintenance Cost
• Affordably Manage COTS Obsolescence
• Improve Usability Through Human-System
Integration (HSI)
AJW -3- 11/19/02
Setting the Context
 ACS is a system of
systems
Battleforce
Ship Infrastructure
(f rom Battlef orce Organization)
...)
 To understand the
requirements for AWS
we need to understand
the services it provides
in collaboration with
external actors and
other ACS subsystems
 Led to the development
of the ACS Enterprise
model
OMG UML for SE
(f rom Combat Support Sy...)
stems)
Contact
(f rom Contact)
Battlegroup
Command
ACS
(f rom Battlef orce Organization)
...)
Ship Command
Authority
System Vendor
(f rom Combat Support Sy...)
stems)
(f rom Battlef orce Organization)
...)
Environment
(f rom Env ironment)
Logistics
(f rom Combat Support Sy...)
stems)
AJW -4- 11/19/02
Focusing on the Command Authority
 Focusing ACS modeling efforts on understanding the tasks
of the major command authorities who utilize the ACS (e.g
TAO, BG commanders, CSOOW)
 Establish a set of high level use cases (tasks) associated
with the activities of these command authorities.
Tactical Picture
Ship Command
Authority
Mission Tasks
Tactical Situation
Management
|_______________________|
Engage
|______________________|
Detect
|___________________________________________________________|
Control
Planning Tasks
Battlegroup
Command
Training
Installation
Maintenance
Configuration
Tasks
|____________________________________________________________________________________|
Support
OMG UML for SE
AJW -5- 11/19/02
ACS Use Cases
 Have developed over 130 ACS use cases through customer/user interviews.
 A “white box” activity diagram for each use case is developed showing the
collaboration of the ACS subsystems (i.e AWS) to satisfy the use case flow.
 Use Cases set the context for Requirements, Test Scenarios, and Training
Material
Light-Off ACS
Prepare to Get Underway
CSOOW
Configure for Underway
Replenishment (UNREP)
(f rom Combat Support ...)
Sy stems)
Prepare to Enter Port
Secure ACS
OMG UML for SE
AJW -6- 11/19/02
Identifying AWS Use Cases
“Turning Over The Watch”
Transition across
swim lane indicates
entity
collaboration.
Flows through the various
activities form the basis of the
use case scenarios
CIC Watchstander
Configure AWS for Watchstander
Activity diagrams model the flow of work and collaboration
among entities (actors, systems or subsystems).
OMG UML for SE
AJW -7- 11/19/02
AWS Use Case Specifications
Black Box Steps are
system responses
that make no
reference to
architectural
elements
Black Box Budgeted
Requirements allow
explicit association of
“ility” requirements to a
black box use case
step.
OMG UML for SE
AJW -8- 11/19/02
Subsystems and Localities
 As AWS use cases are being developed, collaboration (white box
analysis) of notional logical subsystems can be examined to
understand how to decompose the system.
 Gather like activities together into subsystem services
 Minimize dependencies between subsystems (e.g. avoid bi-directional
dependencies)
 At the same time the subsystem services can be allocated to
notional localities thus levying requirements on those localities
(e.g. performance, and capacity).
 Black Box performance requirements are allocated across white
box steps (subsystems and localities).
 End to end timelines are preserved and inconsistencies in allocations to
subsystems and localities are uncovered early
 Re-factoring is essential
OMG UML for SE
AJW -9- 11/19/02
Logical Subsystem
Decomposition
<<subsystem>>
...>>
Mis sion
Management
<<subsystem>>
Operator Support
<<subsystem>>
...>>
Mis sion
Planning
<<subsystem>>
...>>
Mis sion
Readiness
<<subsystem>>
Maintenance
Support
<<subsystem>>
Computing Resource
Management
<<subsystem>>
...>>
ID Services
<<subsystem>>
Tactical Picture
Management
<<subsystem>>
...>>
Environment
Management
<<subsystem>>
Sensor Resource
Management
<<subsystem>>
...>>
Schedule
Services
Any subsystem that provides
services to a human actor will
probably use services from
Operator Support but
dependencies are not explicitly
shown.
<<subsystem>>
...>>
SPY
Management
<<subsystem>>
Weapon Resource
Management
<<subsystem>>
Mis sion Task
Management
<<subsystem>>
...>>
Track
Management
<<subsystem>>
...>>
Training
Management
<<subsystem>>
Excomm Resource
Management
<<subsystem>>
...>>
Doctrine
Services
Logical Decomposition Prevents Stovepiping of Functionality
OMG UML for SE
AJW -10- 11/19/02
AWS Locality Diagram
Localities are stereotyped
nodes representing
groupings of processing
resources
CIC
Bridge
(f rom Combat Inf ormation Center (CIC))
(f rom Bridge)
1
1
<<connection>>
<<connection>>
Connection represents
information path between
two localities.
Aegis LAN
<<connection>>
Crypto Room
1
(f rom Cry pto Room)
<<connection>>
<<connection>>
1
CSMC
(f rom Computer Sy stem Maintenance Central (CSMC))
3
CSER
Characteristics
(Tagged Values) can
be associated with
connections and
localities.
(f rom Combat Sy stem Equipment Room (CSER))
Multiplicity can be used
to establish numbers of
resources for
performance or fault
tolerance.
Locality provides an abstraction to physical deployment and
allow allocation of Technical (“ility”) requirements early in development
OMG UML for SE
AJW -11- 11/19/02
Subsystem Use Case
Development
 Based on the collaborations defined in the white box analysis,
Subsystem use cases can be developed.
 Activity Diagrams
 Sequence Diagrams
 The subsystem use cases are ultimately realized through analysis,
design and code.
 Locality Diagrams form the basis for descriptor node and
deployment diagrams.
 Multiple viable deployments can be realized from the locality diagram
OMG UML for SE
AJW -12- 11/19/02
Domain Object Models
 The domain object model is composed of a set of logically grouped
classes and class diagrams.
 The classes represent real world information the users depend on
to perform tasks (use cases).
 The relationships between information are also captured to illustrate the
associations operators (and systems) make between data or information.
 Information can take many forms both external and internal to the
system
 publications, documents, navy messages, hand written logs
 tracks, doctrine, plans, system status
 Provides system designers with better insight into the users’
domain and can provide guidance for how information should be
represented to the user.
 The Information models provide three major benefits
 Essential for the development of storyboards and user interfaces
 Provide a mechanism to couple what may seem to be a loosely related set of
use cases.
 Provide the framework for the development of analysis and design classes
later in development.
OMG UML for SE
AJW -13- 11/19/02
Domain Object Model Example
Maritime Tactical Messages
OPLAN
Class
Maritime Tactical
Message
Generalization
OPGEN
OPTASK
OPORD
alters
alters
alters
refines
OPSTAT
OPREP
FRAGORDER
Association
OMG UML for SE
OPTASK SUP
AJW -14- 11/19/02
Information and Activities
Object Flows
 UML allows the placement of Class instances (Objects) in
activity diagrams
 Flow arrows can show when classes get instantiated, used or
modified in association with an activity.
 Begin to establish data dependencies between swimlane
entities (e.g. subsystems)
Activities
Objects
Develop Plan
Instance Name :
Class Name
current plan :
Plan
OMG UML for SE
draft doctrine :
Doctrine
Create Doctrine
Object Flow
Show the
instantiation, use
or modification of
classes
AJW -15- 11/19/02
Activity Diagram w/ Objects Example
OMG UML for SE
AJW -16- 11/19/02
Performing Trades
The 7PII UML Model is a powerful tool for
performing different requirements trades
 HSI and Automation
 Requirements Allocation
 Adding new capabilities
OMG UML for SE
AJW -17- 11/19/02
Exploring Automation
 Activity Diagrams and the Information model allow the team
to explore what-if scenarios to support improved HSI and
optimized manning
 Conversion of paper information to integrated electronic
 Synthesis of data into meaningful information
 Identifying deltas to 7PI capability by creating two instances
of the same use case
 “As-is” use cases represent 7PI capability
 “To-Be” use cases represent enhanced capabilities.
<<To Be>>
Manage Contact ID
OMG UML for SE
Manage Contact ID (To Be)
AJW -18- 11/19/02
Requirements Allocation
Update Track ID (To Be)
Sequence diagrams assign
operations to proxy or
analysis classes
: ID Manager
Senerio Description:
This sequence is an
Included Use Case.
In this specif ic senerio
no Ov erridablle Rules
were Violated and no
Non-Ov errideable Rules
were v iolated.
: Track Manager
: System T rack
Repository
: System T rack
History Repository
: Alert Manager
: Excomm
Manager
Test for Overrideable Rules( )
Test for Authorization( )
Recieve ID for Track( )
Update Track Identification( )
Put( )
Send Alert( )
Receive Published Link Tracks( )
Filter T rack( )
Send Track Data Over Links( )
• Operations associated with
subsystem proxy or analysis classes
give clues to possible alternate
allocations of services and lead to
the creation, modification or deletion
of existing subsystems
• Provides a framework for
optimization of allocation
OMG UML for SE
AJW -19- 11/19/02
Adding Capability – New Warfighting Areas
 In order to support potential Missile Defense Agency
activities, the Architecture team explored the possibility of
adding Ballistic Missile Defense capability to the 7PII Model
 Allowed us to assess the ease of inserting new capabilities
into the model and requirements framework.
 What we found
 Requirements elicitation techniques were still applicable (domain experts vice
users)
 Some modifications to existing ACS Use Cases (e.g.new missile type)
 Some new Use Cases to support planning and tactical responses
 Mission Packages provide a mission centric view into a particular capability
which can be used for system development planning purposes.
 Requirements reuse!
BMD Mission
Anatomy Diagram
OMG UML for SE
AJW -20- 11/19/02
Lessons Learned
 UML Is Proving to Be a Powerful Systems Modeling Language
 Better Understanding of the System: People, Software and Hardware
 Use Case and Activity Diagrams Are Excellent Artifacts for Doing Requirements Analysis
and Communicating With the Customer
 Captures Operational Perspective Which is Frequently Lost in an Engineering
Environment.
 Culture Change Is Necessary
 Large Community Rooted in 20+ Years of Legacy
 New Methodologies Blur Engineering Discipline Boundaries (e.g., System, Software,
Testing/verification)
 Early Customer Involvement Is Critical
 Essential for Use Case Analysis
 Helps Streamline the Review Process
 Learn Together
 Strong UML Modelers Are As Important As Domain Experts Early in
Model Development
 Engineers New to UML Tend to Misuse (e.g., Do Functional Decomposition With Use
Case Notation)
OMG UML for SE
AJW -21- 11/19/02