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

1. Application of UML in Aegis Open Architecture Andrew.J.Winkler@lmco.comNovember, 2002 Naval Electronics & Surveillance Systems - Surface Systems Moorestown, New Jersey

2. 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)

3. Sensors and Comms Weapon and CM Incoming Interface Outgoing Interface VLA SM-2 TLAM LINK 4 SM-2 IVA LINK 11 LINK 16 • 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) 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 FCS CEC WCS/FCS C&D IFF TWS C 2 2 P 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. Transition across swim lane indicates entity collaboration. Flows through the various activities form the basis of the use case scenarios 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. 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 Sequence diagrams assign operations to proxy or analysis classes 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)