Upload
vilina
View
42
Download
0
Embed Size (px)
DESCRIPTION
Application of UML in Aegis Open Architecture [email protected] 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 - PowerPoint PPT Presentation
Citation preview
Application of UML in Aegis Open Architecture
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)
AJW -3- 11/19/02 OMG UML for SE
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
AJW -4- 11/19/02 OMG UML for SE
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
(f rom Combat Support Sy stems)...)
ACSBattlegroup Command
(f rom Battlef orce Organization)...)
AJW -5- 11/19/02 OMG UML for SE
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
AJW -6- 11/19/02 OMG UML for SE
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
(f rom Combat Support Sy stems)...)
AJW -7- 11/19/02 OMG UML for SE
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).
AJW -8- 11/19/02 OMG UML for SE
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
AJW -9- 11/19/02 OMG UML for SE
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
AJW -10- 11/19/02 OMG UML for SE
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
AJW -11- 11/19/02 OMG UML for SE
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
AJW -12- 11/19/02 OMG UML for SE
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
AJW -13- 11/19/02 OMG UML for SE
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.
AJW -14- 11/19/02 OMG UML for SE
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
AJW -15- 11/19/02 OMG UML for SE
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
AJW -16- 11/19/02 OMG UML for SE
Activity Diagram w/ Objects Example
AJW -17- 11/19/02 OMG UML for SE
Performing Trades The 7PII UML Model is a powerful tool for
performing different requirements tradesHSI and AutomationRequirements AllocationAdding new capabilities
AJW -18- 11/19/02 OMG UML for SE
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)
AJW -19- 11/19/02 OMG UML for SE
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
AJW -20- 11/19/02 OMG UML for SE
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
AJW -21- 11/19/02 OMG UML for SE
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)