Application of UML in Aegis Open Architecture [e-mail] November, 2002

1
Application of UML in Aegis Open Architecture
Andrew.J.Winkler_at_lmco.comNovember, 2002
Naval Electronics Surveillance Systems -
Surface Systems Moorestown, New Jersey
2
Aegis Combat SystemThe 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)

3
Open Architecture OverviewApproach and Goals
Baseline 7 Phase I Aegis Combat System
NAVSSI
JMCIS
HF, UHF,
HF, UHF,
EXCOM
SATCOM
SATCOM
GWS
(
)
(
)
JTT
2
ADSMARK 6
ICOM/
SGS
ON
-
201
-
CEC
FCS
WCS/FCS
CD
IFF
TWS
C
2
P
2
NETWORK INTERFACES VIA ALIS
(MODEL 5)
VLS
BFTT
EWS
SPY
ACTS REHOST
UWS
UWS
RADARS
SVTT
SVTT
SPS-73
LSE
SPS-67
LSE
ORTS UPDGRADE
AN/SPY
-
1
-
1
LSTP
EWS
SQQ-89
COUNTER
COUNTER
Control
MEASURES
MEASURES
LSE
LSE
RMS
4
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

5
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.

6
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

7
Identifying AWS Use Cases
Turning Over The Watch
Activity diagrams model the flow of work and
collaboration among entities (actors, systems or
subsystems).
8
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.
9
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

10
Logical Subsystem Decomposition
Logical Decomposition Prevents Stovepiping of
Functionality
11
AWS Locality Diagram
Localities are stereotyped nodes representing
groupings of processing resources
Connection represents information path between
two localities.

Characteristics (Tagged Values) can be associated
with connections and localities.
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
12
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

13
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.
  

14
Domain Object Model Example
Class
Generalization
Association
15
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 Instance Name Class Name
Object Flow Show the instantiation, use or
modification of classes
16
Activity Diagram w/ Objects Example
17
Performing Trades

• The 7PII UML Model is a powerful tool for
  performing different requirements trades
• HSI and Automation
• Requirements Allocation
• Adding new capabilities

18
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.

19
Requirements Allocation
20
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!

21
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)