Title: Application of UML in Aegis Open Architecture Andrew.J.Winkler@lmco.com November, 2002
1Application of UML in Aegis Open Architecture
Andrew.J.Winkler_at_lmco.comNovember, 2002
Naval Electronics Surveillance Systems -
Surface Systems Moorestown, New Jersey
2Aegis 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)
3Open 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
4Setting 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
5Focusing 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.
6ACS 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
7Identifying AWS Use Cases
Turning Over The Watch
Activity diagrams model the flow of work and
collaboration among entities (actors, systems or
subsystems).
8AWS 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.
9Subsystems 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
10Logical Subsystem Decomposition
Logical Decomposition Prevents Stovepiping of
Functionality
11AWS 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
12Subsystem 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
13Domain 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.
14Domain Object Model Example
Class
Generalization
Association
15Information 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
16Activity Diagram w/ Objects Example
17Performing Trades
- The 7PII UML Model is a powerful tool for
performing different requirements trades - HSI and Automation
- Requirements Allocation
- Adding new capabilities
18Exploring 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.
19Requirements Allocation
20Adding 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!
21Lessons 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)