Application of UML in Aegis Open Architecture Andrew.J.Winkler@lmco November, 2002

Application of UML in Aegis Open Architecture

[email protected]

November, 2002

Naval Electronics & Surveillance Systems - Surface SystemsMoorestown, New Jersey

AJW -2- 11/19/02 OMG UML for SE

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)


Open Architecture OverviewApproach and Goals

Weapon and CMOutgoing Interface

NAVSSI

EXCOM

JTT

CEC

IFF

C2P(MODEL 5)

EWS

HF, UHF, SATCOM

RADARS

SPS-67

LSTPAN/SPY-1

ORTS UPDGRADE

SPY

C&D WCS/FCS

ADSMARK 6

SGSGWS

FCS

EWS

COUNTERMEASURES

LSE

SVTT

UWS

(2)

Control

TWS

VLS

ICOM/ON-201

SQQ-89

LSE

RMS

JMCIS

2

HF, UHF, SATCOM

-1

BFTT

ACTS REHOST

COUNTERMEASURES

LSE

SVTT

UWS

( )-

LSE

SPS-73

VLASM-2TLAM

SM-2 IVA

LINK 4LINK 11LINK 16

Baseline 7 Phase IAegis Combat System

Sensors and CommsIncoming Interface

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

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)

NETWORKINTERFACES

VIA ALIS


Setting the Context

ACS is a system of systems

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

Ship Infrastructure

(f rom Combat Support Sy stems)...)

Logistics

(f rom Combat Support Sy stems).. .)

Ship Command Authority

(f rom Battlef orce Organization).. .)

Contact

(f rom Contact)

Environment

(f rom Env ironment)

Battleforce

(f rom Battlef orce Organization).. .)

System Vendor


ACSBattlegroup Command

(f rom Battlef orce Organization)...)


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.

Configuration Tasks

Planning Tasks Training MaintenanceInstallation

Tactical Picture Mission Tasks

|______________________| Detect

|___________________________________________________________| Control

|_______________________| Engage

|____________________________________________________________________________________| Support

Tactical Situation Management

Ship Command Authority

Battlegroup Command


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

Configure for Underway Replenishment (UNREP)

Prepare to Enter Port

Secure ACS

CSOOW



Identifying AWS Use Cases

Transition across swim lane indicates

entity collaboration.

CIC Watchstander Configure AWS for Watchstander

“Turning Over The Watch”

Flows through the various activities form the basis of the

use case scenarios

Activity diagrams model the flow of work and collaborationamong entities (actors, systems or subsystems).


AWS Use Case Specifications

Black Box Budgeted Requirements allow

explicit association of “ility” requirements to a

black box use case step.

Black Box Steps are system responses

that make no reference to architectural

elements


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


Logical Subsystem Decomposition

Tactical Picture Management

<<subsystem>>

Mission Planning

<<subsystem>>...>>

Mission Readiness

<<subsystem>>...>>

Mission Task Management

<<subsystem>>

Sensor Resource Management

<<subsystem>>

Weapon Resource Management

<<subsystem>>

Operator Support<<subsystem>>

Maintenance Support

<<subsystem>>

Track Management

<<subsystem>>...>>

Environment Management

<<subsystem>>...>>

Excomm Resource Management

<<subsystem>>

SPY Management

<<subsystem>>...>>

Mission Management

<<subsystem>>...>>

ID Services<<subsystem>>...>>

Computing Resource Management

<<subsystem>>

Training Management

<<subsystem>>...>>

Schedule Services

<<subsystem>>...>>Doctrine Services

<<subsystem>>...>>

Any subsystem that provides services to a human actor wi ll probably use services from Operator Support but dependencies are not explicitly shown.

Logical Decomposition Prevents Stovepiping of Functionality


Multiplicity can be used to establish numbers of

resources for performance or fault

tolerance.

AWS Locality DiagramBridge

(f rom Bridge)

CIC

(f rom Combat Inf ormation Center (CIC))

CSMC

(f rom Computer Sy stem Maintenance Central (CSMC))

CSER

(f rom Combat Sy stem Equipment Room (CSER))

Crypto Room

(f rom Cry pto Room)

Aegis LAN

11

<<connection>>11

<<connection>>

11<<connection>>

33

<<connection>>

11

<<connection>>Connection represents

information path between two localities.

Characteristics (Tagged Values) can be associated with connections and

localities.

Localities are stereotyped nodes representing

groupings of processing resources

Locality provides an abstraction to physical deployment and allow allocation of Technical (“ility”) requirements early in development


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


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.


Maritime Tactical Message

OPSTAT

OPREP

OPLAN OPGEN OPORD

FRAGORDER

alters alters

OPTASK

alters

OPTASK SUP

refines

Domain Object Model Example

Maritime Tactical Messages

ClassGeneralization

Association


Information and Activities

Object FlowsUML allows the placement of Class instances (Objects) in

activity diagramsFlow 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)

Develop Plan

current plan : Plan

Create Doctrine

draft doctrine : Doctrine

ObjectsInstance Name :

Class Name

Object FlowShow the

instantiation, use or modification of

classes

Activities


Activity Diagram w/ Objects Example


Performing Trades The 7PII UML Model is a powerful tool for

performing different requirements tradesHSI and AutomationRequirements AllocationAdding new capabilities


Exploring AutomationActivity 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 electronicSynthesis 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.

Manage Contact ID

<<To Be>>

Manage Contact ID (To Be)


Requirements Allocation : ID Manager : Track Manager : System Track

Reposi tory : Alert Manager : Excomm

Manager : System Track

History Repository

Test for Overrideable Rules( )

Test for Authorization( )

Recieve ID for Track( )

Update Track Identification( )Put( )

Receive Published Link Tracks( )

Fi lter Track( )

Send Track Data Over Links( )

Send Alert( )

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.

Update Track ID (To Be)

ID Manager Interface

ID Manager

Recieve Published System Track()Determine Identification()Refresh Scrub List()Form Q&W Template()Receive Q&W Response()Test for ID Prohibitions()Get Proposed Ident and Attribute Info()Refresh ID Assessment Data in CCRO()Get ID History()Refresh Track ID History()End ID History()Get Confidence Rational()Refresh Confidence Rational Data()End Confidence Rational()Get Current and Proposed ID Data()Refresh Current ID Data()End Current and Previous ID Data()Select Track From Scub List()Update Track ID()Test for Overrideable Rules()Receive Published Track Drops & Merges()Review Flight Schedule()Review Track ID Information()Select Track From TACSIT()Get Guidance Information()Receive Identification and ID Attribute Data()Get Current and Previous ID Data()Get ID Assessment Data()Display Proposed Data()Refresh Identification and ID Attribute Data()Accept ID Change()Request Multiship data via Electronically()Test for Authorization()

Sequence diagrams assign operations to proxy or

analysis classes

• 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


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


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)

Documents

Application of UML in Aegis Open Architecture Andrew.J.Winkler@lmco November, 2002