MINISTRY OF DEFENCE. MOD Architectural Framework Technical Handbook

Transcription

1 MODAF-M MINISTRY OF DEFENCE MOD Architectural Framework Technical Handbook Version August 2005 Prepared by:- Approved by:- MODAF Project Review Board CROWN COPYRIGHT THIS DOCUMENT IS THE PROPERTY OF HER BRITANNIC MAJESTY S GOVERNMENT. This material (other than the Royal Arms and departmental or agency logos) may be reproduced free of charge in any format or medium provided it is reproduced accurately and not used in a misleading context. Where this material is being republished or copied to others, the source of the material must be identified and the copyright status acknowledged. For further information on Crown Copyright policy and licensing arrangements, see the guidance featured on the HMSO website

2 RECORD OF CHANGES This page will be updated and re-issued with each amendment. It provides an authorisation for the amendment and a checklist to the current amendment number. Version August 2005 First MODAF Baseline release MODAF-M7-022 Version 1.0 2

3 MODAF Technical Handbook - Table of Contents Foreword Background Enterprise Architecture, Architectural Frameworks, & MODAF What is Enterprise Architecture? What is an Architectural Framework? Why use MODAF? MODAF Context & Structure MODAF Viewpoints Guide to the MODAF suite of documents Catalogue of MODAF Views New and modified Views Enterprise Reference Model (ERM) MODAF Meta Model (M 3 ) Taxonomies MODAF Tool Support Cohesion of Architecture Views View and Architecture Data Element Relationships Iterative Development Of Products MODAF and UML Further Information Guide to the Technical Handbook Purpose The Technical Handbook Audience The Technical Handbook Sections All-View Products Overview and Summary Information (AV-1) AV-1 Product Description AV-1 UML Representation AV-1 MODAF Meta Model Support Integrated Dictionary (AV-2) AV-2 Product Description AV-2 UML Representation AV2-MODAF Meta Model Support Strategic View Products Capability Vision (StV-1) StV-1 Product Description StV-1 UML Representation StV-1 MODAF Meta Model Support Capability Taxonomy (StV-2) StV-2 UML Representation StV-2 MODAF Meta Model Support Capability Phasing (StV-3) StV-3 Product Description StV-3 UML Representation StV-3 MODAF Meta Model Support Capability Clusters (StV-4) StV-4 Product Description StV-4 UML Representation StV-4 MODAF Meta Model Support Capability to Systems Deployment Mapping (StV-5) StV-5 Product Description StV-5 UML Representation StV-5 MODAF Meta Model Support MODAF-M7-022 Version 1.0 3

4 5.6 Capability Function to Operational Activity Mapping (StV-6) StV-6 Product Description StV-6 UML Representation StV-6 MODAF Meta Model Support Operational View Products High Level Operating Concept (OV-1a, 1b, & 1c) OV-1a Product Description OV-1a UML Representation OV-1a MODAF Meta Model Support OV-1b Product Description OV-1b UML Representation OV-1b MODAF Meta Model Support OV-1c Product Description OV-1c UML Representation OV-1c MODAF Meta Model Support Operational Node Connectivity Description (OV-2) OV-2 Product Description OV-2 UML Representation OV-2 MODAF Meta Model Support Operational Information Exchange Matrix (OV-3) OV-3 Product Description OV-3 UML Representation OV-3 MODAF Meta Model Support Organisational Relationships Chart (OV-4) OV-4 Product Description OV-4 UML Representation OV-4 MODAF Meta Model Support Operational Activity Model (OV-5) OV-5 Product Description OV-5 UML Representation OV-5 MODAF Meta Model Support Operational Activity Sequence & Timing Description (OV-6a, 6b & 6c) Overview of Operational Activity Sequence and Timing Descriptions (OV-6a, 6b, & 6c) OV-6a Product Description OV-6a UML Representation OV-6a MODAF Meta Model Support OV-6b Product Description OV-6b UML Representation OV-6b MODAF Meta Model Support OV-6c Product Description OV-6c UML Representation OV-6c MODAF Meta Model Support Logical Data Model (OV-7) OV-7 Product Description OV-7 UML Representation OV-7 MODAF Meta Model Support System View Products Systems Interface Description (SV-1) SV-1 Product Description SV-1 UML Representation SV-1 MODAF Meta Model Support Systems Communications Description (SV-2a, 2b, 2c) Overview of System Communications Description (SV-2a, 2b, & 2c) SV-2a Product Description MODAF-M7-022 Version 1.0 4

5 7.2.3 SV-2a UML Representation SV-2a MODAF Meta Model Support SV-2b Product Description SV-2b UML Representation SV-2b MODAF Meta Model Support SV-2c Product Description SV-2c UML Representation SV-2c MODAF Meta Model Support Systems-Systems Matrix (SV-3) SV-3 Product Description SV-3 UML Representation SV-3 MODAF Meta Model Support Systems Functionality Description (SV-4) SV-4 Product Description SV-4 UML Representation SV-4 MODAF Meta Model Support Operational Activity to Systems Function Traceability Matrix (SV-5) SV-5 Product Description SV-5 UML Representation SV-5 MODAF Meta Model Support Systems Data Exchange Matrix (SV-6) SV-6 Product Description SV-6 UML Representation SV-6 MODAF Meta Model Support Systems Performance Parameters Matrix (SV-7) SV-7 Product Description SV-7 UML Representation SV-7 MODAF Meta Model Support Systems Evolution Description (SV-8) SV-8 Product Description SV-8 UML Representation SV-8 MODAF Meta Model Support Systems Technology Forecast (SV-9) SV-9 Product Description SV-9 UML Representation SV-9 MODAF Meta Model Support Systems Functionality Sequence & Timing Description (SV-10a, 10b, & 10c) Overview of Systems Functionality Sequence and Timing Descriptions (SV-10A, 10B, & 10C) SV-10a Product Description SV-10a UML Representation SV-10a MODAF Meta Model Support SV-10b Product Description SV-10b UML Representation SV-10b MODAF Meta Model Support SV-10c Product Description SV-10c UML Representation SV-10c MODAF Meta Model Support Physical Schema (SV-11) SV-11 Product Description SV-11 UML Representation SV-11 MODAF Meta Model Support Technical View Products Technical Standards Profile (TV-1) TV-1 Product Description MODAF-M7-022 Version 1.0 5

6 8.1.2 TV-1 UML Representation TV-1 and TV-2 MODAF Meta Model Support Technical Standards Forecast (TV-2) TV-2 Product Description TV-2 UML Representation TV-1 and TV-2 MODAF Meta Model Support Acquisition View Products SoS Acquisition Clusters (AcV-1) AcV-1 Product Description AcV-1 UML Representation AcV-1 MODAF Meta Model Support SoS Acquisition Programme (AcV-2) AcV-2 Product Description AcV-2 UML Representation AcV-2 MODAF Meta Model Support MODAF View and Data Element Relationships About this section View relationship matrix Document Maintenance BIBLIOGRAPHY MODAF Technical Handbook - Table of Figures Figure 2-1: MODAF Viewpoints...14 Figure 2-2: MODAF 1.0 Baseline Products...15 Figure 2-3: Community of Interest Deskbook Scope...16 Figure 2-4: Complete list of MODAF Views...18 Figure 2-5: View Element Dependency Diagram...22 Figure 4-1: Overview and Summary Information (AV-1) - Representative Format...28 Figure 4-2: MODAF Meta Model Excerpt for AV Figure 4-3: Example Taxonomy classifying model elements Figure 4-4: MODAF Meta Model Excerpt for AV Figure 5-1: HLOC Strategic Vision...35 Figure 5-2: Capability Vision for Defence Logistics...35 Figure 5-3: MODAF Meta Model Excerpt for StV Figure 5-4: An example of the StV-2 View - Textual Representation...38 Figure 5-5: An example of the StV-2 View - Graphical Representation...38 Figure 5-6: An example of the StV-2 View - Tabular Representation...39 Figure 5-7: An example of the StV-2 View expressed in UML...40 Figure 5-8: MODAF Meta Model Excerpt for StV Figure 5-9: An example of the StV-3 View...43 Figure 5-10: MODAF Meta Model Excerpt for StV Figure 5-11: Functional Dependency Diagram...47 Figure 5-12: Functional N-Squared Diagram...47 Figure 5-13: UML Representation of StV Figure 5-14: MODAF Meta Model Excerpt for StV Figure 5-15: An example of the StV-5 View...51 Figure 5-16: MODAF Meta Model Excerpt for StV Figure 5-17: Example for StV-6 for hypothetical Land Operational Tasks...54 Figure 5-18: MODAF Meta Model Excerpt for StV Figure 6-1: Graphical Future Rapid Effect Systems (FRES) OV-1a Representation...58 Figure 6-2: MODAF Meta Model Excerpt for OV-1a...59 Figure Extract from an OV-1b Example...61 MODAF-M7-022 Version 1.0 6

7 Figure 6-4: MODAF Meta Model Excerpt for OV-1b...61 Figure 6-5: Example of an OV-1c View...62 Figure 6-6: MODAF Meta Model Excerpt for OV1-c...63 Figure 6-7: Imaginary OV-2 Example...66 Figure 6-8: Example OV-2 from US Navy...67 Figure 6-9: Example OV-2 for Service Provision...68 Figure 6-10: Example UML for OV Figure 6-11: MODAF Meta Model Excerpt for OV Figure 6-12: Joint Force Targeting (from DoDAF Deskbook)...73 Figure 6-13: Notional Strike Mission (from the DoDAF Deskbook)...73 Figure 6-14: MODAF Meta Model Excerpt for OV Figure 6-15: Organisational Relationships Chart (OV-4) Template...77 Figure 6-16: UML Organisational Relationships Chart, OV Figure 6-17: MODAF Meta Model Excerpt for OV Figure 6-18: Operational Activity Hierarchy Chart and Operational Activity Diagram (OV-5) Templates...81 Figure 6-19: Operational Activity Model (OV-5) Template with Notional Annotations...81 Figure 6-20: UML Activity Diagram Swim-Lanes...82 Figure 6-21: UML Activity Diagram (showing actions)...82 Figure 6-22: MODAF Meta Model Excerpt for OV Figure 6-23: Example Operational Rules (OV-6a)...86 Figure 6-24 Example of OV-6a rules shown on an OV-5 UML Product...87 Figure 6-25: MODAF Meta Model Excerpt for OV-6a...87 Figure 6-26: Operational State Transition Description High-Level Template...88 Figure 6-27 UML diagram for Operational State Transition Description OV-6b...89 Figure 6-28: MODAF Meta Model Excerpt for OV-6b...89 Figure 6-29: Operational Event-Trace Description (OV-6c) UML-type...91 Figure 6-30: MODAF Meta Model Excerpt for OV-6c...92 Figure 6-31: Logical Data Model (OV-7) Template...94 Figure 6-32: UML Class Diagram for Logical Data Model (OV-7) Template...94 Figure 6-33: MODAF Meta Model Extract for OV Figure 7-1: Generic SV-1 Diagram Example...99 Figure 7-2: SV-1 Example from US Navy using Swim Lanes Figure 7-3: Example UML for SV Figure 7-4: MODAF Meta Model Extract for SV Figure 7-5: Example System Port Specification Figure 7-6: UML diagram for SV-2a Figure 7-7: MODAF Meta Model Extract for SV-2a Figure 7-8: Example System to System Protocol Stack diagrams Figure 7-9: UML diagram for SV-2c Figure 7-10: MODAF Meta Model Extract for SV-2b Figure 7-11: Example System Connectivity Clusters View Figure 7-12: SV-2c UML Representation Figure 7-13: MODAF Meta Model Extract for SV-2c Figure 7-14: Systems-Systems Matrix (SV-3) Template Figure 7-15: MODAF Meta Model Extract for SV Figure 7-16: Systems Functionality Description (SV-4) Template (Functional Decomposition) Figure 7-17: Systems Functionality Description (SV-4) Template (Data Flow Diagram)..118 Figure 7-18 UML diagram for SV Figure 7-19: UML Use Case Diagram for Systems Functionality Description (SV-4) Figure 7-20: MODAF Meta Model Excerpt for SV Figure 7-21: Operational Activity to Systems Function Traceability Matrix (SV-5) Figure 7-22: Capability to System Traceability Matrix (SV-5) Figure 7-23: MODAF Meta Model Excerpt for SV MODAF-M7-022 Version 1.0 7

8 Figure 7-24: Systems Data Exchange Matrix (SV-6) Template Figure 7-25: MODAF Meta Model Extract for SV Figure 7-26: Systems Performance Parameters Matrix (SV-7) Notional Example Figure 7-27: MODAF Meta Model Extract for SV Figure 7-28: Systems Evolution Description (SV-8) Migration Figure 7-29: Systems Evolution Description (SV-8) Evolution Figure 7-30: MODAF Meta Model Excerpt for SV Figure 7-31: Systems Technology Forecast (SV-9) Notional Example Figure 7-32: Systems Technology Forecast (SV-9) Template Figure 7-33: MODAF Meta Model Extract for SV Figure 7-34: OCL Example Embedded in an SV-4 Product Figure 7-35: MODAF Meta Model Excerpt for SV-10a Figure 7-36: Systems State Transition Description (SV-10b) High-Level Template Figure 7-37: UML Statechart Example Figure 7-38: MODAF Meta Model Excerpt for SV-10b Figure 7-39: Systems Event-Trace Description (SV-10c) Template Figure 7-40: MODAF Meta Model Excerpt for SV-10c Figure 7-41: Physical Schema (SV-11) Representation Options Figure 7-42: Class Diagram for Physical Schema (SV-11) Figure 7-43: MODAF Meta Model Excerpt for SV Figure 8-1: An example of the TV-1 View Figure 8-2: MODAF Meta Model Excerpt for TV-1 and TV Figure 8-3 Technical Standards Forecast (TV-2) Figure 8-4: MODAF Meta Model Excerpt for TV-1 and TV Figure 9-1: Example DPA Acquisition Clusters Figure 9-2: Example AcV-1 for Hypothetical ISTAR Cluster Figure 9-3: Example UML Representation of AcV Figure 9-4: MODAF Meta Model Excerpt for AcV Figure 9-5: Examples of Lines of Development coloured icons Figure 9-6: Example AcV-2 View for a hypothetical programme of projects Figure 9-7: MODAF Meta Model Excerpt for AcV Figure 10-1: MODAF View relationship matrix MODAF-M7-022 Version 1.0 8

9 Foreword 1. An effects based approach to military operations demands that we combine military capabilities in time and space, to an ever increasing tempo, in order to achieve the desired outcome. To achieve this, we must master the complex interaction of weapons, Platforms, sensors and people, in order to maximise their combined strengths and to minimise any potential weaknesses. We seek to do this through our adoption of Network Enabled Capability, integrating existing capabilities into an increasingly coherent System of Systems. 2. At the same time, perpetual pressure on Defence spending means that we must seek maximum return on our investments and drive inefficiency out of our operations. 3. Our greatest enemy in this regard is complexity and we must find effective ways to overcome it. One key to achieving the simplicity we seek is to focus on the decision-making process and the information flows that must support effective decision making and subsequent action. 4. The MOD Architectural Framework (MODAF) offers invaluable assistance in our struggle for simplicity, as it provides a common language and common formats for the capture and shared use of trusted data. It is therefore my intent that we adopt an architectural approach, grounded in MODAF, to our day-to-day business. This Technical Handbook explains how you can begin to use MODAF to articulate your business in a manner that will aid collective understanding, increase efficiency and enhance effectiveness; I commend it to you. MODAF-M7-022 Version 1.0 9

10 1 Background 5. The MOD Architectural Framework (MODAF) is an enabler for managing complexity. It provides a specification of how to represent an integrated model of an enterprise, from the operational / business aspects to the Systems that provide capability, with appropriate Standards and programmatic aspects. It assists in managing complexity by providing a logical, standardised way to present and integrate models of the enterprise. By covering both the operational and technical aspects across the enterprise, MODAF-compliant Architectures enable all communities of interest to gain the essential common understanding that will be required to deliver the benefits to be derived from Network Enabled Capability (NEC) MODAF provides a rigorous method for understanding, analysing, and specifying: Capabilities, Systems, Systems of Systems (SoS), Organisational Structures and Business Processes. It is intended to facilitate the successful delivery of NEC. The key benefits that MODAF delivers are improvements to the specification and implementation of interoperability between Systems. MODAF supports a wide variety of MOD processes, including: capability management, acquisition and sustainment. 1.1 Enterprise Architecture, Architectural Frameworks, & MODAF What is Enterprise Architecture? 7. An Enterprise Architecture is the formal description of the structure and function of the components of an enterprise, their interrelationships, and the principles and guidelines governing their design and evolution over time. Note: Components of the enterprise can be any element that goes to make up the enterprise and can include people, processes and physical structures as well as engineering and information systems 8. Enterprise Architecture (EA) is about managing and understanding complexity covering how business / operational requirements are met by technical and operational capability. The term architecture is apt EA is all about providing blue-prints (models) of the organisation and the systems that support it. In order to provide coherent and consistent models, it is necessary to have a framework which defines the different types of model that can be used, and how those models inter-relate. MODAF is a framework for MOD architectures, both in the business-space and the battle-space. 9. Architectures can be viewed as models which support business processes by providing a data-based representation of that business. This representation can be used inter alia: in analysis, for the articulation of issues and requirements, as a support to planning, and as a means of solution design and validation. Architectures are developed at a level of granularity that is appropriate for a given objective. Using an architecture framework, Architectures can be developed for the smallest sub-system or for an entire enterprise What is an Architectural Framework? 10. An Architectural Framework (AF) is a specification of how to organise and present architectural models. Because Enterprise Architecture is such an all-encompassing discipline, and because the enterprises it describes are often large, it can result in very complex models. To manage this complexity, an AF defines a standard set of model categories (called Views ) which each have a specific purpose. These views are often 1 Network Enabled Capability a system with three essential elements: sensors (to gather information); a network (to fuse, communicate and exploit the information); and strike assets to deliver military effect. See NEC: Next Steps - Progress and Review D/CMIS/2/1, April MODAF-M7-022 Version

11 categorised by the domain they cover e.g. operational / business, technical, etc. which are known in MODAF as Viewpoints 2, An AF defines a standard set of business and technical information about an enterprise (or aspects thereof). The purpose of the AF may be to identify elements of this information that will be mandatory to produce within the enterprise or to act as a guide to which types of information may be of most value in analysing aspects of an Enterprise Architecture. The AF usually takes the form of a set of standard Viewpoints and Views on the enterprise Architectural Framework Viewpoints 12. The Architectural Framework Viewpoints provide consistent perspectives of an Architecture and they enable a user to articulate and analyse issues and requirements, and specify, design and validate solutions across a wide range of activities. 13. The MODAF Viewpoints and their constituent Views are described in this document. The usage of these Views within key Communities of Interest are described in the MODAF Deskbooks Architectural Framework Meta Models 14. Views alone only provide consistency in terms of the type of information produced i.e. humans can recognise that one View is a systems model, whilst another is a process model. However, the same information may be represented in more than one View, and there may be important relationships between the information in different Views that should be captured. This consistency between Views is provided by a reference model which identifies all the types of architectural elements represented across all the Views, and the relationships between those concepts. The reference model (or meta model in the case of MODAF) therefore provides semantic rigour for the Architectural Framework. 15. Many of the benefits from using an architectural approach will ultimately come about from the ability to share, integrate, search and re-use architectural information across an enterprise. In order for the architectural information to be stored, managed and queried electronically, the reference model that underpins the Views needs to support the sharing of Architectural Products between tools and the implementation of an architectural repository that stores those Products and the meta-data relating to those Products. Also, although the a meta model describes generic types of architectural information and their relationships, if re-use and integration of Architectural Products is required, those Products must utilise a common Taxonomy too. This ensures that each instance of an Architectural Element 4 (e.g. organisation, system, activity, etc) uses a commonly agreed and shared definition for its name Architectural Framework Taxonomies 16. A Taxonomy provides a standard structured dictionary for an Architecture. A Taxonomy constrains the diversity of an Architecture to ensure consistency across an enterprise, and alignment with a business strategy. 17. The purpose of the MODAF Taxonomy [ IA/02/16, ERMcm05, version 1.0] is to provide a standard set of terminology and reference data to support: 2 A Viewpoint is a collection of views. Viewpoints are usually categorised by domain for example, in MODAF there are Acquisition, Strategic, Operational, System and Technical Viewpoints. 3 The MODAF definition of Viewpoint and View differs from that of IEEE 1471 due to the fact that MODAF is an approach for defining Enterprise Architectures whereas the emphasis in IEEE 1471 is on technical architectures. 4 An instance or configuration of a discrete architectural feature. MODAF-M7-022 Version

12 a. Architectural coherence across the MOD by ensuring all MODAF users employ the same terminology to describe the elements in their Architectures. b. Architectural comparison using the same base definitions for standard organisations, systems, activities, etc. allows comparison of different aspects of the business. c. Data exchange clarity information exchanged between architectural tools can be fully defined using the Taxonomy. 18. Like its US counterpart, DoD Architectural Framework (DoDAF), the MODAF specification relies on using a Taxonomy to support the architectural Views. Whereas the DoDAF Taxonomy is specified in text in the Volume II document, the MODAF Taxonomy is to be published electronically 5, and made accessible to users and architectural tools and repositories. The Taxonomy has technical definitions that will underpin Architectures and their development. The suite of MODAF documents also includes a glossary and acronym list. Whilst these will be consistent with the Taxonomy their purpose is only to support the readability of the MODAF documents Why use MODAF? 19. There is an increase in the need to support flexible, highly responsive joint and coalition operations and a growing need to deliver end to end military capability, whilst delivering more for less and ensuring interoperability. Our need in the future is for flexible and adaptable armed forces properly supported to carry out the most likely expeditionary operations Rt. Hon G Hoon MP July Defence white paper Delivering security in a changing world 20. Military strategies and systems have become far more complex and, although ad-hoc acquisition will still occur, the conflict between satisfying short term needs yet increasing medium and long term complexity needs to be firmly managed. Projects and programmes now link and overlap. There are multiple operational, technical, and service boundaries emerging, which must be managed coherently and there is overlapping functionality in subsystems. 21. NEC is a key component of efforts to meet changing requirements. NEC enables the military to federate systems, sensors, and effectors and, hence, to improve overall military effectiveness. NEC is the linking of sensors, decision makers and weapon systems so that information can be translated into synchronised and overwhelming military effect at optimum tempo Capability Manager (Information Superiority), CM(IS), July There is a requirement for a more structured approach to the management of complexity and a concomitant requirement to balance all relevant user perspectives. Architectural frameworks support such requirements, and the most mature and widely adopted Architectural Framework in the defence sector is DoDAF which has been developed over a number of years by the US Department of Defense (DoD). 23. CM(IS) recognised DoDAF as the most appropriate Architectural Framework in his NEC Next Steps Paper to the Joint Capabilities Board (JCB). 5 The Taxonomy will be documented using the W3C's Web Ontology Language (OWL), see MODAF-M7-022 Version

13 "Working with major stakeholders (DG(Info), DCSA, IA and others) DEC CCII has identified the US Department of Defense Architecture Framework (DoDAF) as the most appropriate framework to underpin the development of NEC. CM(IS), NEC Next Steps Paper, April DoDAF has its origins in the C4ISR community and is seen as a fundamental part of the DoD drive towards Net-Centric Warfare (NCW). MODAF is based on the DoDAF specification. MODAF uses aspects of the existing DoDAF without alteration together with additional Viewpoints that are required to support UK MOD processes, procedures, and organisational structures. MODAF-M7-022 Version

14 2 MODAF Context & Structure 2.1 MODAF Viewpoints 25. MODAF is the MOD s framework for conducting Enterprise Architecture and provides a means to model, understand, analyse and specify Capabilities, Systems, Systems of Systems (SoS) and Business Processes. MODAF consists of the six Viewpoints that are shown in Figure 2-1. Strategic Viewpoint Documents the strategic picture of how military capability is evolving in order to support capability management and equipment planning Operational Viewpoint Documents the operational processes, relationships and context to support operational analyses and requirements development Systems Viewpoint Documents system functionality and interconnectivity to support system analysis and through-life management Acquisition Viewpoint Documents acquisition programme dependencies, timelines and DLOD status to inform programme management Technical Viewpoint Documents policy, standards, guidance and constraints to specify and assure quality expectations All Views Provides summary information for the architecture that enables it to be indexed, searched and queried Figure 2-1: MODAF Viewpoints 26. MODAF consists of 38 Views, each of which can be used to represent a particular aspect of the enterprise. These Views are categorised into the six Viewpoints shown above. The purpose of each of the 38 Views is different some provide high-level summary information about the enterprise (e.g. organisational structure, programme management, etc.), others describe some specific aspect (e.g. system interfaces), whilst others serve to describe the relationships between different aspects of the enterprise (e.g. process mapping). 2.2 Guide to the MODAF suite of documents 27. MODAF is defined by a suite of documents and this Technical Handbook forms part of the MODAF 1.0 baseline documentation as shown in Figure 2-2. MODAF-M7-022 Version

15 MODAF Executive Summary MODAF Overview MODAF Technical Handbook COI Deskbo MODAF COI ok Deskbo COI Deskbook ok Viewpoint Overview Meta Model Taxonomy MODAF Acronyms List MODAF Glossary of Terms Figure 2-2: MODAF 1.0 Baseline Products 28. The main elements of the MODAF baseline documentation are: a. Executive Summary [MODAF-M09-001] provides a brief summary of the purpose of MODAF and the benefits that may be accrued from its use. b. MODAF Overview [MODAF-M09-002] describes what MODAF is, why it should be used and details the process for developing architectures c. MODAF Technical Handbook [MODAF-M07-022] provides details of the construction of MODAF Views and their relationship to the MODAF Meta Model (M 3 ), [IA/02/16, ERcm04,Version 1.0]. This is supported by: i. View Overview a short summary of each View intended for quick reference by MOD users ii. M 3 used to define the architectural objects that are permitted in MODAF Views and their relationships with each other. iii. Taxonomy provides the approved names and definitions for architectural objects to be used within the MOD s architectures d. MODAF Deskbooks describe how users within particular communities in the MOD are expected to utilise MODAF architectures to support their processes. e. MODAF Acronym and Abbreviation List [MODAF-M07-018] and Glossary of Terms [MODAF-M07-017] these documents define the commonly used terminology in the MODAF Document Suite. MODAF-M7-022 Version

16 29. The Deskbooks are aimed at specific Communities of Interest (COIs). The boundaries between these communities are not always distinct, but it has been necessary to draw boundaries for the purposes of the Deskbooks. Each COI is defined in terms of its relationship to the main MOD processes (see Figure 2-3). Whilst these do not describe the whole of the MOD s processes as described in the Business Management System (BMS), they do cover the core processes around acquisition and military operations. 30. It should be noted that the COI names referred to in Figure 2-3 are merely convenient labels to apply to communities / groups that are engaged in similar activities. For instance, the scope of the Acquisition COI aligns broadly with that of the DPA IPTs (i.e. largely equipment focussed from Concept stage through to delivery into service). Obviously this scope is somewhat more limited than the full Smart Acquisition definition of Acquisition which encompasses all DLODs and the entire lifecycle. However, collectively the MODAF COIs do encompass all of the DLODs and cover the entire MOD acquisition lifecycle. Concepts & Doctrine Concepts & Doctrine Future Op Needs Doctrine Capability Gaps Customer 2 Operations Customer 1 Acquisition Capability Management C A D M I D Funded C A D M I T Options Sustainment Constraints Figure 2-3: Community of Interest Deskbook Scope 31. The high level scope of these COIs is: a. Concepts and Doctrine - the development of analytical concepts (e.g. Joint High Level Operational Concept), applied concepts (e.g. Joint Fires) and in-service doctrine (e.g. SOPs and TTPs). b. Customer 1 the monitoring of capability gaps against future needs, building the Equipment Programme (EP) and ownership of User Requirements Documents (URDs) for new capabilities. c. Acquisition the development and fielding of new military capabilities, the primary focus is up to the acceptance into service of a fully operational capability. d. Sustainment the processes to maintain military capability in line with the relevant Through Life Management Plan while recognising the in-theatre Sustainment roles of the relevant Second Customer s Pivotal Managers 6. e. Customer 2 the Core Leadership and Pivotal Management roles as defined in Smart Acquisition 7 and described further in the Joint and Single Service 2nd Customer Handbooks 8. 6 Covered in the Customer 2 Deskbook as the Maintain Military Capability process 7 For further detail, see Smart Acquisition Handbook, available at MODAF-M7-022 Version

17 2.3 Catalogue of MODAF Views 32. Each Acquisition View (AcV), Technical View (TV), System View (SV), Operational View (OV), Strategic View (StV) and All View (AV) is summarised in Figure 2-4. For convenience the figure has been presented on the adjacent two whole pages. 2.4 New and modified Views 33. In order to maximise the ability to exploit Architectures produced in MODAF format it is important that they fully comply with the MODAF standards, which includes not only the use of MODAF Views but also the MODAF Meta Model and Taxonomy. The use of MODAFcertified tools by Architecture development teams will ensure that most of these requirements are satisfied and hence provide assurance of interoperability between tools and with the MOD Architectural Repository (MODAR). 34. It is possible for users to create Views that look similar to those specified in MODAF, but which do not conform to the full standard. In such cases it is unlikely that the resulting Architecture will be able to be electronically exchanged with the MODAR repository and therefore might not be accessible to others running architectural queries. The resulting Architecture would become, to a greater or lesser degree, isolated from the main MODAR body of architectural knowledge. 35. However, there may be good reasons for wishing to modify MODAF Views such as adding further overlays to enhance understanding. Where this is the case, the user wishing to develop modified Views should first contact the MODAF team and/or IA (see Section 2.13 for points of contact) for advice on how to implement the required enhancements in a manner that maximises tool interoperability and hence the future exploitation of the resulting Architecture. 2.5 Enterprise Reference Model (ERM) 36. The ERM [ IA/02/16, ERMcm06, Version 1.1] is a conceptual information model which provides a mechanism for the MODAF stakeholders to represent their requirements for MODAF. The concepts and relationships it defines are very high level and may not correspond directly (i.e. 1:1) with the elements that can be shown in a MODAF View. The ERM is not implemented in any way by MODAF. Instead, the concepts it describes are realised in the M MODAF Meta Model (M 3 ) 37. For an Architectural Framework to be useful, the information described in each Viewpoint must be consistent, and integrated across the Viewpoints. To achieve this, MODAF has a Meta Model which describes the complete set of Architectural Elements and the relationships between them within and across the Viewpoints. This means that common information between the Viewpoints can be recorded once and re-used either in the file used by the architectural tool, or in a repository. For example, a system first defined in SV-1 can be reused by SV-2, StV-3, StV-5, etc., but the information about that system is stored only once in the underlying data set. 8 Customer 2 (Core Leadership) is undertaken by single-service Chiefs to provide overall strategic management of individual Services and their professional direction. Core Leadership provides advice to Customer 1 on the full range of factors contributing to military capability across the DLODs. Customer 2 (Pivotal Management) is undertaken by those who use the equipment in-service (primarily the front line and training commands) in order to provide the user perspective and manage allocated resources to achieve the required output. MODAF-M7-022 Version

18 View Category View Number View Name View Description All Views AV-1 Overview and Summary Information Scope, purpose, intended users, depiction of environment, analytical findings. Also provides version information about the architecture All Views AV-2 Integrated Dictionary Defines the taxonomy elements used by the architecture Strategic StV-1 Capability Vision Outlines the vision for a Capability area over a particular time frame Strategic StV-2 Capability Taxonomy The Capability Taxonomy (StV-2) View provides a structured list of capabilities and sub-capabilities (known as capability functions) that are required within a capability area during a certain Period of Time. Strategic StV-3 Capability Phasing Captures the planned availability of Capability at different points in time, i.e. different Periods of time Strategic StV-4 Capability Clusters Provides a means of analysing the main dependencies between Capabilities Strategic StV-5 Capability to Systems Deployment Mapping Strategic StV-6 Capability Function to Operational Mapping Operational OV-1a High Level Operational Concept Graphic Operational OV-1b Operational Concept Description Operational OV-1c Operational Performance Attributes Operational OV-2 Operational Node Connectivity Description Operational OV-3 Operational Information Exchange Matrix Operational OV-4 Organisational Relationships Chart Operational OV-5 Operational Activity Model Operational OV-6a Operational Rules Model Operational OV-6b Operational State Transition Description Operational OV-6c Operational Event Trace Description Shows the planned Capability deployment as systems, equipment, training, etc and their interconnection by organisation / period of time Describes the mapping between capability elements and operational activities that can be performed by using them and thereby provides a link between capability analysis and activity analysis High-level graphical/textual description of operational concept Provides a supplementary description of the High Level Operational Concept Graphic Provides detail of the operational performance attributes associated with the scenario / use case represented in the High Level Operational Concept Graphic Operational nodes, connectivity, and information exchange needlines between nodes Information exchanged between nodes and the relevant attributes of that exchange Organisational, role, or other relationships among organisations Capabilities, operational activities, relationships among activities, inputs, and outputs; overlays can show cost, performing nodes, or other pertinent information Identifies business rules that constrain operation Identifies business process responses to events Traces actions in a scenario or sequence of events Operational OV-7 Logical Data Model Documentation of the system data requirements and structural business process rules of the Operational Viewpoint Figure 2-4: Complete list of MODAF Views MODAF-M7-022 Version

19 View Category View Number View Name View Description System SV-1 Systems Interface Description Identification of systems nodes, systems, and system items and their interconnections, within and between nodes System SV-2a System Port Specification System ports and protocols used by those ports when communicating with other systems. System SV-2b System To System Port Connectivity Protocol stack used by a connection between two ports. The ports may be on different systems. System SV-2c System Connectivity Clusters Individual connections between system ports, and grouping into logical connections between nodes. System SV-3 Systems-Systems Matrix Relationships among systems in a given architecture; can be designed to show relationships of interest, e.g., system-type interfaces, planned vs. existing interfaces, etc. System SV-4 Systems Functionality Description System SV-5 Operational Activity to Systems Functionality Traceability Matrix System SV-6 Systems Data Exchange Matrix System SV-7 Systems Performance Parameters Matrix System SV-8 Systems Evolution Description System SV-9 Systems Technology Forecast Functions performed by systems and the system data flows among system functions Mapping of systems back to capabilities or of system functions back to operational activities Provides details of system data elements being exchanged between systems and the attributes of that exchange Performance characteristics of Systems Viewpoint elements for the appropriate time frame(s) Planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving a current system to a future implementation Emerging technologies and software/hardware products that are expected to be available in a given set of time frames and that will affect future development of the architecture System SV-10a System Rules Model Identifies constraints that are imposed on systems functionality due to some aspect of systems design or implementation System SV-10b Systems State Transition Description Identifies responses of a system to events System SV-10c Systems Event-Trace Description Identifies system-specific refinements of critical sequences of events described in the Operational Viewpoint System SV-11 Physical Schema Physical implementation of the Logical Data Model entities, e.g., message formats, file structures, physical schema Technical TV-1 Technical Standards Profile Listing of standards that apply to all the Views in a given architecture Technical TV-2 Technical Standards Forecast Description of emerging standards and potential impact to all the Views in a given architecture, within a set of time frames Acquisition AcV-1 System of System Acquisition Clusters Acquisition AcV-2 System of System Acquisition Programmes Provides detail of how Acquisition tasks are grouped to improve management of interoperability and programmatic dependencies Provides an overview of either the complete acquisition programme or a subset of projects Figure 2-4 (continued): Complete list of MODAF Views MODAF-M7-022 Version

20 38. The M 3 is the information model for MODAF, defining the structure of the underlying architectural information that is presented in the Views. The goal is that MODAF tools are model-driven i.e. the Views that are presented to the user are snapshots of underlying architectural data which is stored in the tool or in a repository. 39. The M 3 defines a Unified Modelling Language (UML) profile by extending the UML 2.0 meta model which in turn, specifies the structure and content of XMI files used for exchanging information between MODAF tools. The appropriate section of meta model needed to exchange the information for a MODAF View is provided in the definition for the View. It should be noted that the classes shown for one View may be used in several other Views. 40. The classes defined in the M 3 specify the allowable UML stereotypes that may be exchanged in an XMI file. As it is a meta model, all relationships that feature in a View are also modelled as classes. Rather than define a class for every conceivable item that could appear in a View, the meta model defines generic classes and allows references to the MODAF Taxonomy. For example, the MOD would be represented in XMI as an Organisation stereotype, with a tagged value referring to the element in the Taxonomy which says Ministry of Defence. 41. Excerpts of the M 3 are presented for each view in this Handbook. Readers should be clear that the model is contiguous and integrated it is merely presented view-by-view, and common elements are used between views. It is this usage of common elements (e.g. nodes being used in OV-2 and SV-1) that integrates the views. The M 3 is published in a navigable electronic (HTML) format, and is available from the Integration Authority (IA). 42. There are some key points that implementers must bear in mind when reading the M 3 model excerpts shown in this Handbook: a. The UML modelling tool used to produce the diagrams did not implement the relationship. Hence a generalisation relationship has been used, with a discriminator of. b. In order to constrain the usage of the model, it is necessary to define which stereotyped elements can relate to each other. The approach used in constrain is to redefine or subset existing UML 2.0 metaclass relationships. Although this is strictlyspeaking not allowed in a profile abstract syntax, it is a convenient and easily understandable way of constraining the model. c. Base UML 2.0 metaclasses are shown in green d. Abstract classes are used extensively to provide a logical selection between stereotypes when relationships are constrained to more than one stereotype. Abstract classes are shown in blue. e. Context attributes are extensively used especially in Composite Class models. This is to allow relationships to refer to specific usages of a class. For example, an activity may be conducted at all nodes of a certain class, but in some cases there may be activities that are conducted at the node ONLY when it is used in context of another node or location. 43. For more information on the use of XMI in MODAF, refer to the document XMI UML & MODAF [IA/02/16-ERMcm03] 44. Version 1.0 of the M 3 is presented in this Handbook. This version is the first release and so has not been tested in commercial implementations. It is likely that modifications will be required to the M 3 as tool vendors begin to implement their XMI interfaces. Anyone planning to implement the M 3 should contact the IA who will provide the very latest version of the model and announce changes to the implementation community as they arise. MODAF-M7-022 Version

21 2.7 Taxonomies 45. The MODAF Taxonomy is to be developed in a related project in conjunction with the communities of interest. The Integration Authority (IA) is coordinating current work and subsequent ownership will rest with Director General Information (DG Info). 2.8 MODAF Tool Support 46. The tool(s) selected for Architecture development are intended to assist the architect in producing consistent Products by performing cross-product checking. The selected tool(s) should also include a mechanism for storing, updating, and retrieving architectural data and their relationships and an ability to automatically generate an integrated dictionary. In addition, the tool should be capable of importing/exporting complete or partial (i.e. View by View) Architectures as an XMI file conforming to the profile defined in the M Cohesion of Architecture Views 47. Most graphical Views (e.g., OV-2, OV-5, StV-5, SV-1, and SV-4) permit the modelling of their Architecture data elements using decomposition (i.e. several diagrams of the same View may be developed for the same Architecture, where each diagram shows an increasing level of detail). Within each Architecture, all Views developed need to remain consistent with respect to the level of detail. For example, if one diagram of OV-2 Operational Nodes is developed that shows aggregated Nodes only, then it is imperative that the corresponding OV-5 be developed to show only those operational activities that are meaningful with respect to these Operational Nodes. Similarly, the exchanges shown in an OV-3 should remain at an appropriate level of aggregation to the corresponding Operational Nodes shown in OV-2 (and not their subordinate Operational Nodes). 48. MODAF Views also make extensive use of overlay as a graphical technique for showing aggregations e.g. Operational Nodes may be shown overlaid on System Nodes on an SV-1 diagram. Architects using UML 2.0 tools will find that Composite Class diagrams are a useful way to represent many of these Products, and the M 3 makes use of Composite Classes in many of the views e.g. OV-2, SV-1, StV-2, etc View and Architecture Data Element Relationships 49. MODAF is a model-driven Architecture. The M 3 defines the types of Architectural Element that may constitute a MODAF Architecture, and the allowable relationships between those elements. This Handbook defines MODAF in terms of its Views, but a MODAF Architecture shall be a contiguous and connected representation of the enterprise. This is achieved by using the same Architectural Elements in multiple Views. For example, operational activities defined in OV-5 may be presented in OV-2, OV-6 and StV-6 Products those activities are specified only once and re-used. In addition, some MODAF Views link the information in one Product to another e.g. SV-5 links OV-5 and SV-4. Figure 2-5 illustrates the key M 3 definitions that connect the Views into a contiguous Architectural Framework. 50. Section 10 of this document presents an alternative way of representing the dependencies between Views, but does not make use of the M 3 definitions. MODAF-M7-022 Version

22 StV-1 Capability Vision StV-4 Capability Cluster Capability Dependency SV-9 StV-3 StV-5 Capability Link covered by MODAF view (labelled on line) OV-4 SV-4 Role Post Function Organization Function Flow System Event SV-7 SV-1 SV-3 SV-2 SV-8 System SV-6 System Port System Connection SV-2d Port Connection StV-2 StV-6 OV-2 Node OV-5 OV-6 Operational Event Operational Activity Activity Flow OV-3 Needline (Information) Operational State Operational Constraint SV-6 Information Element Information Exchange SV-10 System State System Constraint AcV-1 AcV-2 Project Milestone OV-7 Relationship SV-11 Entity Attribute Datamodel SV-5 Figure 2-5: View Element Dependency Diagram MODAF-M7-022 Version

23 2.11 Iterative Development Of Products 51. Architectural Products may be described at varying levels of detail for example, an architect may wish to produce a high-level, summary OV-2 which hides some detail, and a set of detailed OV-2s. This approach allows MODAF to be used in iterative design processes, where the Views are progressively filled in with more detail as the Architecture emerges from the design and development process. MODAF Views have dependencies between them, and the frequent changes (which are an aspect of an iterative development process) can ripple across many Views for example, changes in an OV can drive changes in the SV and TV Views. 52. During this iterative development process, different models are developed at varying levels of abstraction with Products that trace from one model to another. At the highest level of abstraction a minimal set of Products may be developed to produce a single model of the Architecture (denoted Model A). 53. This initial model may comprise only highly abstract/generic sets of Operational Nodes, operational activities, and so forth. Later, when new details are added and the Architecture is expanded to show more design detail, plus additional Products as necessary, a new model is developed. (Model B, consisting of modified Model A Views plus additional Views as necessary). 54. The new Products that make up Model B include and trace back to the original group of Products (which make up Model A of the Architecture). The Operational Node of Model A's OV-2 Product (as part of Model A) may have been used to represent an aggregated organisation or command (one that may consist of multiple subordinate Operational Nodes) but it is deemed unnecessary to show those subordinate Nodes at the Model A level. 55. In Model B, the Operational Node of Model A s View may be expanded to show the subordinate Nodes. No new root level Framework Operational Nodes are introduced at this level that do not trace back to the previous model. For example, if (in the process of model refinement) it is determined that an Operational Node is part of the Architecture, and that this Node is not yet a part of any of the aggregated Operational Nodes of OV-2 included in Model A, then Model A s OV-2 is revised to include the newly identified node. Model B s OV-2 may then include that subordinate Node - which will be a decomposition of the Model A node, and will trace back to that node. 56. Further information on the approach to developing MODAF Architectures and iterative development can be found in Section 5 of the MODAF Overview MODAF and UML 57. During the last few years UML has emerged as the dominant language for Object Oriented modelling. The Object Management Group (OMG) characterises UML as a general-purpose modelling language for specifying, visualising, constructing and documenting the artefacts of software systems, as well as for business modelling and other non-software systems [OMG, 2000]. 58. Some MODAF Views lend themselves well to UML representation, whilst others are inappropriate. Where UML is appropriate, this Handbook provides UML examples for relevant Views. The UML representation is provided to assist architects who wish to use Object Modelling techniques in their MODAF products. 59. It should be noted that this Handbook does not mandate the use of UML in developing MODAF Products. However, architects wishing to use UML to represent MODAF Products shall ensure that the UML they produce is in line with the UML profile described by the M 3. The meta model defines an abstract syntax for UML to be used with MODAF. This means that modellers shall only use the MODAF stereotypes (specified by M 3 ) when producing their MODAF-M7-022 Version

24 architectural diagrams. Not every MODAF View is well suited to UML, but for those Views where it is applicable, UML examples conforming to the MODAF profile are shown. In addition, this document shows the appropriate excerpt of the M 3 for each View including those that are not suited to UML representation, as the M 3 defines the XMI exchange format for every MODAF Architectural Product Further Information 60. Further information on MODAF and other related topics can be found in a. The MODAF Executive Summary b. The MODAF Overview. 61. Contact details for persons who can provide further information, or for more specific advice and guidance, are provided in Section 11. MODAF-M7-022 Version

25 3 Guide to the Technical Handbook 3.1 Purpose 62. The purpose of this document is to provide the reference definition for the Viewpoints and Views used within MODAF. 3.2 The Technical Handbook Audience 63. This Technical Handbook is specifically intended for the following audiences: a. Experienced Enterprise Architects requiring the definitive specification for MODAF, after having read the Executive Summary and appropriate Deskbook b. Data modellers, tool developers, and engineers who are implementing Architecture data repositories for storing and manipulating MODAF Architecture data elements c. Those involved in the selection of a MODAF compliant software tool in support of development of an Architecture d. Advanced MODAF users seeking to develop MODAF. 3.3 The Technical Handbook Sections 64. The Technical Handbook is divided into the following sections: a. Foreword b. Section 1 - Background c. Section 2 - MODAF Context and Structure d. Section 3 Guide to the Technical Handbook e. Sections 4 to 9. Each one of these sections defines one of the suite of six Viewpoints that combine to form MODAF. Each Section has the following sub-sections: i. Product Definition - A brief overview of the MODAF View. ii. Product Purpose - A description of the purpose of the View, i.e. explaining how it is used. Actual usage scenarios are not provided in this document (see the COI Deskbooks). However, references to real-world applications may be included to assist in the explanation of the Product purpose. iii. Detailed Product Description - Expands on the information presented in the first and second sections and usually includes narrative details about a Product and its representation, and one or more generic templates (or examples) for the View. iv. UML Representation - In cases where the Views are well-suited to representation using the UML, suggested examples are presented. If a MODAF tool does use UML to represent a MODAF View, that UML will conform to the profile defined in the M 3. v. MODAF Meta Model Support - Shows the meta model elements with their accompanying definitions that are relevant to the View and that define the structure of MODAF exchange files (XMI). f. Section 10 - This Section summarises the major relationships between various MODAF Products/views. g. Section 11 Contact information for maintenance of this document h. Section 12 - Bibliography MODAF-M7-022 Version

26 4 All-View Products 65. AVs provide information pertinent to the entire Architecture. There are two AV Views: a. Overview and Summary Information (AV-1) b. Integrated Dictionary (AV-2). 66. A description for each of these Views is included below. MODAF-M7-022 Version

27 4.1 Overview and Summary Information (AV-1) AV-1 Product Description Product Definition 67. The Overview and Summary Information provides executive-level summary information in a consistent form that allows quick reference and comparison between Architectures. AV-1 includes assumptions, constraints, and limitations that may affect high- level decisions relating to the Architecture Product Purpose 68. AV-1 contains sufficient textual information to enable a reader to select one Architecture from among many to read in more detail. AV-1 serves two additional purposes. In the initial phases of Architecture development, it serves as a planning guide. Upon completion of an Architecture, AV-1 provides summary textual information about the Architecture Detailed Product Description 69. The AV-1 Product is a (text) summary of a given Architecture and it documents the following descriptions: a. Architecture Project Identification Identifies the Architecture project name, the architect, and the organisation developing the Architecture. It also includes assumptions and constraints, identifies the approving authority and the completion date, and records the level of effort and costs (projected and actual) required to develop the Architecture. b. Scope Identifies the Views and Products that have been developed and the temporal nature of the Architecture, such as the time frame covered, whether by specific years or by designations such as current, target, transitional, and so forth. Scope also identifies the organisations that fall within the scope of the Architecture. c. Purpose and viewpoint Explains the need for the Architecture, what it will demonstrate, the types of analyses (e.g., Activity-Based Costing) that will be applied to it, who is expected to perform the analyses, what decisions are expected to be made on the basis of an analysis, who is expected to make those decisions, and what actions are expected to result. The viewpoint from which the Architecture is developed is identified (e.g., planner or decision maker). d. Context Describes the setting in which an Architecture exists. Context includes such things as: mission, doctrine, relevant goals and vision statements, concepts of operation, scenarios, information assurance context (e.g. types of system data to be protected, such as classified or sensitive but unclassified, and expected information threat environment), other threats and environmental conditions, and geographical areas addressed, where applicable. Context also identifies authoritative sources for the rules, criteria, and conventions that were followed. e. Tools and File Formats Used Identifies the tool suite used to develop the Architecture and file names and formats for the Architecture and each Product. f. Findings States the findings and recommendations that have been developed based on the architectural effort. Examples of findings include: identification of shortfalls, recommended system implementations, and opportunities for technology insertion. During the course of developing an Architecture, several versions of a Product may be produced. An initial version may focus the effort and document its scope, the organisations involved, and so forth. After other Products within an Architecture s scope have been developed and MODAF-M7-022 Version

28 verified, another version may be produced to document adjustments to the scope and to other aspects of the Architecture that may have been identified. Costing information, such as integration costs, equipment costs and other costs can be included in the findings. 70. After an Architecture has been used for its intended purpose, and the appropriate analysis has been completed, yet another version may be produced to summarise these findings for high level Decision makers. In this version, the AV-1 Product and a corresponding graphic in the form of an OV-1 Product serve as an executive summary of the Architecture. 71. Figure 4-1 shows a representative format for an AV-1 Product. Figure 4-1: Overview and Summary Information (AV-1) - Representative Format AV-1 UML Representation 72. There is no specific UML diagram that is applicable to the AV-1 View. UML tools used for analysis and design usually allow for the addition of documentation to annotate the model/architecture being designed. It will be possible for documentation developed for AV-1, to be input via a documentation field in a UML modelling tool, if so desired. MODAF-M7-022 Version

29 4.1.3 AV-1 MODAF Meta Model Support Architecture Package (from UML::Classes::Kernel) Comment (from UML::Classes::Kernel) -architect:string -creatingorganization:string -assumptionsandconstraints:string -approvalauthority:string -datecompleted:string -purpose:string -viewpoint:string -toolsused:string -summaryoffindings:string -recommendations:string + annotatedarchitecture {redefines annotatedelement } ArchitectureMetaData -name:string -dublincoreelement:string -modmetadataelement:string Figure 4-2: MODAF Meta Model Excerpt for AV The <<Architecture>> package contains all the architectural elements for a given enterprise architecture project. There are a number of properties (tagged values) pre-defined for the architecture. However, an architect may wish to append additional information about the architecture using the <<ArchitectureMetaData>> stereotype. 74. The model elements used in AV-1 are: a. Architecture - A specification of a system of systems at a technical level which also provides the business context for the system of systems. b. ArchitectureMetaData - If the meta data corresponds to the Dublin Core Meta-Data Standard, then the meta-data element name should be listed here MODAF-M7-022 Version

30 4.2 Integrated Dictionary (AV-2) AV-2 Product Description 75. The Integrated Dictionary contains classifications of Architectural Elements that are used in a given Architecture, and the textual definitions of those classifications. Note1: The intention is for MODAF to use standardised, electronic taxonomies. In most cases, AV-2 will simply consist of a reference to the taxonomies used for the particular Architecture. However, should a potential user not have access to the on-line Taxonomy (e.g. he/she is using a secure network), the AV-2 will carry a date-stamped snapshot of the Taxonomy elements used by the Architecture. Note2: The MODAF Taxonomy (and therefore the successful use of MODAF in the MOD) will use the MOD Taxonomy specification which is to be developed by DG-Info. When the nature of the Taxonomy implementation and content is known, MODAF users will receive further guidance on Taxonomy usage Product Purpose. 76. AV-2 allows the set of Architectural Products to stand alone so that they can be read and understood, either by reference to an online Taxonomy, or by replicating the Taxonomy locally. AV-2 is an accompanying reference to other Products, and its value lies in unambiguous definitions. The key to long-term interoperability can reside in the accuracy and clarity of these definitions Detailed Product Description. 77. AV-2 defines terms used in an Architecture, but it is more than a simple glossary, it is a Taxonomy i.e. a hierarchy of classifications. In the case of MODAF, those classifications are types of Architectural Element. For most Architectural Elements defined in the M 3 (and therefore each Architectural Product that can appear in a View), there will be a set of classifications in the Taxonomy (see Figure 4-3) MODAF Meta-Model system node Example Taxonomy business system operational node system node weapon system A system which has the capability to A system which manages the HR system accounts system hub equipment platform A system which manages the A system which manages the etc Figure 4-3: Example Taxonomy classifying model elements. MODAF-M7-022 Version

31 78. The Taxonomy shall provide clear English descriptions of each classification, and define the specialisation relationships between the classifications which form the hierarchy. The goal is for MODAF Architectures to make reference to an on-line Taxonomy. In this case, the information presented in an AV-2 View will be derived directly from the on-line Taxonomy. In cases where the on-line Taxonomy is not available (e.g. because of network restrictions), the AV-2 acts as a local replica, containing a snapshot of the on-line Taxonomy which has been date-stamped. 79. There is no specification about how an AV-2 will be presented to the user it is left to tool vendors to decide how best to integrate the Taxonomy into their modelling tools. However, if AV-2 is to be presented in document form, it will be as a table, consisting of at least the following five columns: a. ID b. Name c. Description d. Creation Date e. Status (online or offline) 80. The MODAF Taxonomy differs from DoDAF in that it only contains classifications. There is no intention to use the Taxonomy to define commonly used structures i.e. a library of common architectural parts. Such a library, should it be required, would be a feature of the MODAR. 81. Use of taxonomies to classify Architectural Products has the following benefits over freetext labelling: a. Provides common understanding between parties who need to exchange Architectural Products b. Provides consistency across Products c. Provides consistency across Architectures d. Facilitates Architecture development, validation, maintenance, and re- use e. Traces Architecture data to authoritative data sources 82. The M 3 provides high-level definitions of Architectural Products. When those definitions require further classification, the meta model class makes reference to appropriate Taxonomy elements. Architectural Products may be classified by more than one Taxonomy element e.g. a document may be classified as a technical specification, a PDF Document and as restricted. It is possible to apply Taxonomy classifications to any Architectural Product, and therefore to most classes in the M AV-2 UML Representation 83. There is no specific UML diagram that is applicable to the AV-2 View. It is possible to present the Taxonomy classifications used as UML classes. However, given the number of classifications that could be used, this is neither a practical or desirable presentation approach for taxonomies. MODAF-M7-022 Version

32 4.2.3 AV2-MODAF Meta Model Support TaxonomyReference -taxonomyurl:string -classname:string -taxonomyversion:string -taxonomydate:string Comment (from UML::Classes::Kernel) Figure 4-4: MODAF Meta Model Excerpt for AV The MODAF taxonomy is to be specified using the OWL-DL language, part of the W3C's semantic web suite of standards. AV-2 taxonomies are also represented as OWL-DL. Projects may extend the taxonomy with their own specific elements. The <> stereotype is used to assign a taxonomy element (OWL class) to any element in the architecture. 85. Users/vendors may also wish to embed RDF tags in M 3 XMI exchange files to enable semantic web tools to search file contents. 86. The model elements used in AV-2 are: a. TaxonomyReference - A TaxonomyReference may be applied to any element in an architecture (including the <<Architecture>> itself. Guidelines for which taxonomy entries are applicable to which architectural element types will be published with the MODAF Taxonomy.. MODAF-M7-022 Version

33 5 Strategic View Products 87. MODAF adds the Strategic Viewpoint to the core DoDAF Viewpoints (AV, OV, SV, TV). The StVs have been introduced to support the capability management process. There are six StV Products: a. Capability Vision (StV-1) b. Capability Taxonomy (StV-2) c. Capability Phasing (StV-3) d. Capability Clusters (StV-4) e. Capability to Systems Deployment Mapping (StV-5) f. Capability Function to Operational Mapping (StV-6) 88. A description of each of these Views is included below: MODAF-M7-022 Version

34 5.1 Capability Vision (StV-1) StV-1 Product Description Product Definition 89. The Capability Vision (StV-1) defines the strategic context for a group of capabilities. StV- 1 Views are usually textual descriptions of the capabilities being analysed or procured. The Views are high-level and describe capabilities using terminology which is easily understood by non-technical readers (though they may make extensive use of military terminology and acronyms that are clearly defined in the AV-2 View) Product Purpose 90. The purpose of an StV-1 is to provide a strategic context for the capabilities described in the Architecture. It also provides a high-level scope for the Architecture which is more general than the scenario-based scope defined in an OV-1. The different Periods of Time are described in detail by the StV-3 View Detailed Product Description 91. An StV-1 Capability Vision is usually presented as text, with accompanying illustrations, where needed, for clarification. There is no prescribed diagrammatic specification for StV-1. Text (with optional illustrations) is the preferred format, as the aim is to provide a pre-amble and high-level summary for the capabilities to be addressed by the Architecture. 92. An StV-1 Capability Vision will begin by describing the high-level concept. This concept will then be further augmented by describing the high-level operational goals and strategy in military capability terms. As a general rule, the StV-1 View is not intended to specify the system requirements, or even the user requirements. Rather, it has the role of setting the scope for the Architecture in terms of future or current military capability vision. 93. The information contained in an StV-1 View is most likely to have originated from operational concepts and research communities. The information will provide guidance on future capabilities and allow equipment capability specialists to identify future needs. The exception to this is when a MODAF Architecture is used to analyse an existing system - e.g. when reverse engineering a system for integration or upgrade purposes. In this case, the StV-1 role changes slightly in that it will define what the original capability vision for the system was, and what capabilities are to be realised by the integration or upgrade. The StV-1 View is high-level in nature and does not specify the success criteria for an Architecture. StV- 2 provides metrics against each capability which may be used to measure successfully fielded capability. 94. An example StV-1 capability vision for the MOD High Level Operating Concept (HLOC) is shown in Figure 5-1. The capability vision for logistics (taken from the MOD Acquisition Management System (AMS) website) is shown in Figure 5-2. MODAF-M7-022 Version

35 UNCLASSIFIED THE UK JOINT HIGH LEVEL OPERATIONAL CONCEPT CAPPING PAPER 101. Fighting power comprises conceptual, moral and physical components. The conceptual component of joint fighting power was articulated in UK Joint Vision, where the importance of the enduring nature of the Principles of War was endorsed. The Vision provided broad guidance for future capabilities in the form of a joint High Level Operational Concept (HLOC), an effects based framework for operations and a description of capability as seven discrete but closely interlocking components. However, UK Joint Vision did not develop the conceptual components in detail. Using the Defence Capability Framework, this Analytical Concept describes the components of capability in sufficient detail to inform Joint Operational Concept Committee stakeholders, particularly the single Services, who are developing their own high level operational concepts in parallel. The three components of capability, Command, Inform and Operate, form the capability backbone of the HLOC around which considerations for the remaining four components Prepare, Project, Protect and Sustain have been woven to form the complete concept. The concept addresses the 2020 timeframe, assessed as the best compromise between the need to break free from the dominance of current systems4 without venturing into the purely speculative. It has also been harmonised with US joint concepts, noting the clear guidance from COS that we must be able to operate with but not necessarily as our close allies. OPERATE CORE CONCEPT An agile task-oriented joint force with freedom of action to synchronise effects throughout the Battlespace and with maximum potential to exploit fleeting opportunities. Figure 5-1: HLOC Strategic Vision Figure 5-2: Capability Vision for Defence Logistics MODAF-M7-022 Version

36 5.1.2 StV-1 UML Representation 95. There is no specific UML diagram that is applicable to the StV-1 View StV-1 MODAF Meta Model Support Interval (from UML::CommonBehaviors::SimpleTime) EffectivityConstrainedItem CapabilityVision (from MODAF::Capabilities) -title:string { subsets constraineditem} TimePeriod + effectivityperiod { redefines specification } EffectivityConstraint Comment (from UML::Classes::Kernel) { subsets max} { subsets min} Constraint (from UML::Classes::Kernel) ISO8601DateTime TimeExpression (from UML::CommonBehaviors::SimpleTime) Figure 5-3: MODAF Meta Model Excerpt for StV The <<CapabilityVision>> stereotype is used to capture the Capability Vision text (using XHTML if formatted text is required). The time-dependent aspect of the vision is achieved by applying an <<EffectivityConstraint>> to the <<CapabilityVision>>. 97. The model elements used in StV-1 are: a. CapabilityVision - A description of the overall aims of an enterprise over a given period of time. <<CapabilityVision>> is a stereotype of UML::Comment and the body of the comment shall be represented as XHTML. If plain text is required, then no HMTL tags should be embedded. b. EffectivityConstrainedItem - An item whose existence is contrained by an <<EffectivityConstraint>> - i.e. something which is valid for a time period. c. EffectivityConstraint - Specifies that the constraineditem has a time-based existence (effectivity) d. ISO8601DateTime - A date and time specified in the ISO8601 date-time format including timezone designator (TZD): YYYY-MM-DDThh:mm:ssTZD So, 7:20pm and 30 seconds on 30th July 2005 in the CET timezone would be represented as " T19:20:30+01:00" e. TimePeriod - A period of time, defined by start and end dates - sometimes termed an "Epoch" in the MOD. Time periods may overlap. MODAF-M7-022 Version

37 5.2 Capability Taxonomy (StV-2) StV-2 Product Description Product Definition 98. The Capability Taxonomy (StV-2) View provides a structured list of capabilities and subcapabilities (known as capability functions9) that are required within a capability area during a certain Period of Time Product Purpose 99. The StV-2 View is used to support the Capability Audit process, providing a structured set of capabilities. In addition it can be used as a source document for the development of highlevel use cases and Key User Requirements (KUR) Detailed Product Description 100. The StV-2 View is used to capture and organise the capability functions - required for the vision set out in the Capability Vision View (StV-1) - into a structured list The structured list provided in the StV-2 View will be a comprehensive list of the capabilities that will need to be delivered during a particular period of time. The list is structured hierarchically, and each capability is, where necessary, sub-divided into subcapabilities and/or functions, in order to provide clarity and the appropriate level of granularity required by subsequent processes in the capability management process. All terms used in the StV-2 will be expressed only in non-platform specific based terms - i.e. these terms are military capability based, not equipment focused. An StV-2 Product will be developed for each period of time of interest In addition to the capability nomenclature, appropriate quantitative attributes and metrics for that specific capability or function needs to be included e.g. the required speed of processing, the rate of advance, the maximum detection range, etc. These attributes and metrics will remain associated with the capability whenever it is used across the MODAF framework. The quantitative values expressed may be linked to specific Periods of time, or be 'as-is' values and/or or 'to-be' targets The StV-2 View has no mandated structure although the format selected must be able to support the representation of a structured/hierarchal list. This structure may be delivered using textual, tabular or graphical methods. The associated attributes and metrics for each capability function can either be included on the main StV-2 View, or in tabular format as an appendix if the inclusion of the attributes and metrics would over complicate the presentation of the View Examples of an StV-2 View for Command Battlespace Management (Land), CBM(L), capability functions are included in Figure 5-4, Figure 5-5, and Figure 5-6: 9 It became apparent in developing the Strategic Viewpoint that what some users regard as capability functions are regarded as capabilities by other users. For this reason, the MODAF specification and the M 3 do not distinguish between a capability and a capability function capabilities may simply be organised into a hierarchy. MODAF-M7-022 Version

38 Figure 5-4: An example of the StV-2 View - Textual Representation Figure 5-5: An example of the StV-2 View - Graphical Representation MODAF-M7-022 Version

39 Figure 5-6: An example of the StV-2 View - Tabular Representation StV-2 UML Representation 105. The StV-2 View can be represented easily in UML. An example of the StV-2 View expressed as a Composite Structure Diagram in UML is shown in Figure 5-7 below. MODAF-M7-022 Version

40 <<Capability>> Command Battlespace Management <<Capability>> :Decision Support <<Capability>> :Operational Planning <<Capability>> :Operational Analysis <<Capability>> :Information Management and Acquisition <<Capability>> :Information Management <<Capability>> :Analysis <<Capability>> :Effects <<Capability>> :Targeting <<Capability>> :Plan Engagement <<Capability>> :Mission Rehearsal <<Capability>> :Fusion <<Capability>> :Fusion <<Capability>> :Situational Awareness <<Capability>> :Quality Assurance <<Capability>> :Quality Assurance <<Capability>> :Intelligence <<Capability>> :Dissemination <<Capability>> :Dissemination <<Capability>> :Functional Planning Support <<Capability>> :STAR <<Capability>> :Conduct Engagement Figure 5-7: An example of the StV-2 View expressed in UML StV-2 MODAF Meta Model Support Property (from UML::CompositeStructures::InternalStructures) Class (from UML::CompositeStructures::StructuredClasses) CapabilityComposition (from MODAF::Capabilities) + parentcapability {redefines class} + childcapability {redefines type} Capability (from MODAF::Capabilities) UnitOfMeasure + uom {redefines datatype} PhysicalProperty + assigneditem {redefines class} PropertyAssignedItem -maxvalue:literalspecification[0..1] -minvalue:literalspecification[0..1] DataType (from UML::Classes::Kernel) Property (from UML::Classes::Kernel) Class (from UML::Classes::Kernel) Figure 5-8: MODAF Meta Model Excerpt for StV-2 MODAF-M7-022 Version

41 106. StV-2 Capability Breakdowns are represented as composite class models, using <<CapabilityComposition>> stereotypes to link a parent <<Capability>> to a child. Metrics for the capabilities are modelled by <<PhysicalProperties>> which specify the minimum and maximum value for the capability metric The model elements used in StV-2 are: a. Capability - A high level user requirement, usually functional. A capability may have performance metrics represented as Physical Properties. Note that some capabilities might be called "Capability Functions" - MODAF does not distinguish between Capability Functions and Capabilities, other than by virtue of their position in a hierarchy, defined by <<CapabilityComposition>> b. CapabilityComposition - A parent-child relationship between two capabilities i.e. the relationship indicates one capability (child) is a sub-capability of the other (parent). Although the MOD tends to work in terms of capabilities and capability functions, it is not always apparent that there is any difference between them other than their relative positions in a capability taxonomy, which is specified by the <<CapabilityComposition>> relationship. Note: The initial intention was to re-use the SysML <<Requirement>> stereotype specialised to <<Capability>>. However, the nested-classifier approach used in SysML does not lend itself to the reality of MOD Capability development where the same capability function may appear in different places in the capability hierarchy. It is also clear from the SysML documentation that <<Requirement>> is purely a System Requirement, which precludes its use for CRD and URD purposes. c. PhysicalProperty - A property of something in the physical world, expressed in amounts of a unit of measure. The property may have a required value - either specified by the defaultvalue from uml::property attribute, or the minvalue and maxvalue to specify a required range. d. PropertyAssignedItem - The abstract superclass of all classes which may have physical properties e. UnitOfMeasure - A determinate amount or quantity adopted as a standard of measurement for other amounts or quantities of the same kind. MODAF-M7-022 Version

42 5.3 Capability Phasing (StV-3) StV-3 Product Description Product Definition 108. The Capability Phasing (StV-3) View provides a representation of the available military capability at different points in time or during specific Periods of time Product Purpose 109. StV-3 Products support the Capability Audit process and similar processes used across the different COIs by providing a method to identify gaps or duplication in capability provision Detailed Product Description 110. The StV-3 View is used to represent the planned or current availability of military capability at different points in time or during specific Periods of time. The View is created by analysing programmatic project data to determine when Systems providing elements of military capability are to be delivered, upgraded and/or withdrawn (this data may be provided in part by an SoS Acquisition Programmes (AcV-2) View). The Systems identified are structured according to the required capabilities determined in the Capability Taxonomy (StV- 2) View and the timescales/periods of time appropriate An StV-3 Product can be used to assist in the identification of capability gaps/shortfalls (no fielded capability to fulfil a particular capability function) or capability duplication/overlap (multiple fielded capabilities for a single capability function). Where a capability cannot be equated on a one-to-one mapping with a particular System, further analysis can be assisted using the information provided in a Capability to Systems Deployment Mapping (StV-5) Product The StV-3 View is most easily presented in a tabular form typically with the structured list of required capability functions (derived from the Capability Taxonomy (StV-2) View) running in one direction and timescale/periods of time running in the other. At each rowcolumn intersection, the System that delivers the Capability within that time period (or Epoch) is displayed - if the availability of the Capability spans multiple periods of time then this is indicated by an elongated colour-coded 'bar'. If there are no Systems that satisfy the Capability in that period of time then a blank space will be left. It should be noted that many systems may satisfy a particular capability One possible template for the StV-3 View is shown in Figure 5-9. The capabilities defined in StV-2 are shown as grey bars, with their sub-capabilities shown beneath. MODAF-M7-022 Version

43 Capability by Capability Function & Requirements Capability Category Decision Support period of time period of time 1 period of time 2 period of time 3 period of time 4 Now Command Support Decision Support Interoperability period of time period of time defined By key infrastructure insertion points Functional Planning Support Functional Planning Support Interoperability IS Infrastructure Communications Infrastructure Systems within category Asset Management/ Tasking STAR Product Management STAR Sensors STAR STAR Interoperability Phasing of individual systems Targeting Plan Engagement Conduct Engagement EFFECTS Effects Interoperability Effectors Capability gaps Capability shortfalls Enabling Projects StV-3 UML Representation Figure 5-9: An example of the StV-3 View 114. There is no specific UML diagram applicable to the StV-3 View. MODAF-M7-022 Version

44 5.3.3 StV-3 MODAF Meta Model Support Property (from UML::CompositeStructures::InternalStructures) ResourceForCapability (from MODAF::Capabilities) Class (from UML::CompositeStructures::StructuredClasses) + resource {redefines type} CapabilityComposition (from MODAF::Capabilities) + parentcapability {redefines class} + childcapability {redefines type} Capability (from MODAF::Capabilities) Resource + fulfilledcapability {redefines client} + capability {redefines class } Usage (from UML::Classes::Dependencies) CapabilityFulfilment (from MODAF::Capabilities) { subsets supplier} FieldedCapability (from MODAF::Capabilities) System (from MODAF::Systems) -doctrine:constraint[1..*] EffectivityConstrainedItem { subsets constraineditem} EffectivityConstraint Constraint (from UML::Classes::Kernel) Interval (from UML::CommonBehaviors::SimpleTime) + effectivityperiod {redefines specification} TimePeriod Figure 5-10: MODAF Meta Model Excerpt for StV Although UML is not the ideal diagramming approach for StV-3, it is still possible to represent the concepts in an StV-3 product using the UML Meta Model (with appropriate stereotypes and constraints). The key to understanding how the MODAF Meta model is used for StV-3 (and for StV-5) is the <<FieldedCapability>> stereotype. This is a type of node which is composed of resources (systems only for StV-3) which satisfy a capability. The assertion that a capability is realised by a <<FieldedCapability>> is via the <<CapabilityFilfilment>> relationship (UML:Usage). <<CapabilityFulfilment>> is subject to dated effectivity, representing the time period during which the <<FieldedCapability>> realises the <<Capability>> The model elements used in StV-3 are: a. Capability - A high level user requirement, usually functional. A capability may have performance metrics represented as Physical Properties. Note that some capabilities might be called "Capability Functions" - MODAF does not distinguish between Capability Functions and Capabilities, other than by virtue of their position in a hierarchy, defined by <<CapabilityComposition>> MODAF-M7-022 Version

45 b. CapabilityComposition - A parent-child relationship between two capabilities i.e. the relationship indicates one capability (child) is a sub-capability of the other (parent). Although the MOD tends to work in terms of capabilities and capability functions, it is not always apparent that there is any difference between them other than their relative positions in a capability taxonomy, which is specified by the <<CapabilityComposition>> relationship. Note: The initial intention was to re-use the SysML <<Requirement>> stereotype specialised to <<Capability>>. However, the nested-classifier approach used in SysML does not lend itself to the reality of MOD Capability development where the same capability function may appear in different places in the capability hierarchy. It is also clear from the SysML documentation that <<Requirement>> is purely a System Requirement, which precludes its use for CRD and URD purposes. c. CapabilityFulfilment - An assertion that a capability can be met by a <<FieldedCapability>>. d. EffectivityConstrainedItem - An item whose existence is contrained by an <<EffectivityConstraint>> - i.e. something which is valid for a time period. e. EffectivityConstraint - Specifies that the constraineditem has a time-based existence (effectivity) f. FieldedCapability - A combination of organisational aspects (with their competencies) and equipment that combine to provide a capability. A <<FieldedCapability>> must be guided by doctrine which may take the form of <<Standard>> or <<OperationalConstraint>> stereotypes g. Resource - Something that is able to supply functionality, information or material. h. ResourceForCapability - Relates a <<FieldedCapability>> to a resource that contributes towards achieving the capability - e.g. a type of system operated by an organisation with the appropriate competence. i. System - A coherent combination of physical artefacts, energy and information, assembled for a purpose. j. TimePeriod - A period of time, defined by start and end dates - sometimes termed an "Epoch" in the MOD. Time periods may overlap. MODAF-M7-022 Version

46 5.4 Capability Clusters (StV-4) StV-4 Product Description Product Definition 117. The Capability Clusters (StV-4) View describes the relationships between capabilities. It also defines logical groupings of capabilities Product Purpose 118. The StV-4 View is intended to provide a means of analysing the dependencies between capabilities and between capability clusters. The groupings of capabilities are logical, and the purpose of the groupings is to guide acquisition the dependencies and clusters may suggest appropriate liaisons between acquisition projects in order to get the overall military capability Detailed Product Description 119. An StV-4 View shows the capabilities (or capability functions) which are of interest to the Architecture. It groups those capabilities into logical groupings ( clusters ), based on the need for those elements to be integrated. These clusters serve to inform the acquisition process and the Capability Phasing (StV-3) View The elements in an StV-4 View are not intended to represent individual systems or items of equipment military capability may be satisfied by a group of systems, and an individual system can satisfy more than one capability see Section 5.5 Capability to Systems Deployment Mapping (StV-5) The preferred approach for describing an StV-4 View is graphical, and there are a number of potential approaches. Since the elements in an StV-4 View are essentially functional i.e. they describe a required capability the graphical notation is derived from the functional domain of systems engineering. The mandated notation is a functional dependency diagram which shows how functions are clustered together and the relationships between the individual functions or clusters of functions. An example functional dependency diagram is shown in Figure 5-11 (and a UML variant using composite classes is shown in Figure 5-13). It may also be useful to supplement the functional dependency diagram with a functional n-squared diagram see Figure MODAF-M7-022 Version

47 command battlespace management decision support intelligence operational analysis operational planning situational awareness mission rehearsal STAR information management information management & acquisition effects targeting plan engagement conduct engagement Figure 5-11: Functional Dependency Diagram A B C D E F G H I J A B C D E F G X X X X X X X H X I X J X X A = Intelligence B = Operational Analysis C = Operational Planning D = Situational Awareness E = Mission Rehearsal F = STAR G = Information Management H = Targeting I = Plan Engagement J = Conduct Engagement Figure 5-12: Functional N-Squared Diagram MODAF-M7-022 Version

48 5.4.2 StV-4 UML Representation 122. StV-4 Views lend themselves well to UML representation. Capabilities are represented as stereotyped classes, with sub-capabilities contained within them (which may involve many levels of containment). Dependencies between capabilities are shown as stereotyped UML dependency relationships. <<Capability>> Command Battlespace Management <<Capability>> :Intelligence <<Capability>> :Operational Analysis <<Capability>> :Decision Support <<Capability>> :Operational Planning <<Capability>> :Situational Awareness <<Capability>> :Mission Rehearsal <<Capability>> :Information Management and Acquisition <<Capability>> :STAR <<Capability>> :Information Management <<Capability>> :Effects <<Capability>> :Targeting <<Capability>> :Plan Engagement <<Capability>> :Conduct Engagement NOTE: In UML, a dependency or usage relationship has the arrow at the supplier (i.e. non-dependent) end which results in UML diagrams for StV-4 having reversed dependency arrows compared to a non-uml example. Figure 5-13: UML Representation of StV-4 MODAF-M7-022 Version

49 5.4.3 StV-4 MODAF Meta Model Support Class (from UML::CompositeStructures::StructuredClasses) Property (from UML::CompositeStructures::InternalStructures) Dependency (from UML::Classes::Dependencies) Capability (from MODAF::Capabilities) + childcapability {redefines type} + parentcapability {redefines class} CapabilityComposition (from MODAF::Capabilities) + dependentcapability {redefines client} + providercapability {redefines supplier} CapabilityDependency (from MODAF::Capabilities) Figure 5-14: MODAF Meta Model Excerpt for StV An StV-4 product is represented as a composite class model with <<CapabilityDependency>> relationships between the assembly properties (<<CapabilityComposition>>) of dependent capabilities The model elements used in StV-4 are: a. Capability - A high level user requirement, usually functional. A capability may have performance metrics represented as Physical Properties. Note that some capabilities might be called "Capability Functions" - MODAF does not distinguish between Capability Functions and Capabilities, other than by virtue of their position in a hierarchy, defined by <<CapabilityComposition>> b. CapabilityComposition - A parent-child relationship between two capabilities i.e. the relationship indicates one capability (child) is a sub-capability of the other (parent). Although the MOD tends to work in terms of capabilities and capability functions, it is not always apparent that there is any difference between them other than their relative positions in a capability taxonomy, which is specified by the <<CapabilityComposition>> relationship. NOTE: The initial intention was to re-use the SysML <<Requirement>> stereotype specialised to <<Capability>>. However, the nested-classifier approach used in SysML does not lend itself to the reality of MOD Capability development where the same capability function may appear in different places in the capability hierarchy. It is also clear from the SysML documentation that <<Requirement>> is purely a System Requirement, which precludes its use for CRD and URD purposes. c. CapabilityDependency - A relationship which asserts that a capability (tocapability) is dependent on another (fromcapability) capability. MODAF-M7-022 Version

50 5.5 Capability to Systems Deployment Mapping (StV-5) StV-5 Product Description Product Definition 125. The Capability to Systems Deployment Mapping (StV-5) shows deployment of systems in types of organisations (e.g. echelons), and the connections between those systems, to satisfy the military capability for a particular period of time (or Epoch). When appropriate and if necessary the View can show how all relevant DLODs combine to provide the fielded capability Product Purpose 126. The StV-5 View is used to support the capability management process. Specific types of analysis that can be supported include: a. Capability redundancy/overlap/gap analysis; b. Identification of deployment level shortfalls; c. Identification of System connectivity issues; d. Requirements for System interoperability by Organisation; e. Identification of System legacy issues; and f. Assessment of Capability and System options Detailed Product Description 127. In order to conduct a comprehensive analysis, several StV-5 Views are created to represent the Periods of time that are being analysed. Although the StV-5 Views are represented separately, Systems and other DLODs may exist in more than one View. The information used to create the StV-5 is drawn from other MODAF Views (StV-2, StV-4, OV-2, SV-3, AcV-2, etc), and includes: capability functions, System connectivity, Organisational structures, period of time definitions, and Programmatic information The StV-5 View is based on a tabular representation with the appropriate Organisational structure represented by one axis, and the capability functions by the other axis. Graphical objects representing Systems are placed in the relevant positions relative to these axes. Interconnection links connect Systems that are dependent and/or have interaction with other systems. Systems can be represented by multiple Views corresponding to the periods of time for which those systems are in-service. The colour coding of a System or DLOD remains unchanged across periods of time in order to identify the period of time when a System entered service. See Figure 5-15 below: MODAF-M7-022 Version

51 Period of Time Target Location Acquisition SA Ops Planning & Execution Effec Delivery t BDA Joint HQ SATELLITE Strike Command EF EF RM RN JOCS ATG MORTAR W FG ARMY BISA AFV ISTAR E3 WATCH - KEEPER Figure 5-15: An example of the StV-5 View StV-5 UML Representation 129. There is no specific UML diagram that is applicable to the StV-5 View. MODAF-M7-022 Version

52 5.5.3 StV-5 MODAF Meta Model Support In StV-5 usercontext & systemcontext shall be Properties stereotyped as <<ResourceForCapability>> SystemUsage (from MODAF::Systems) -usercontext:property -systemcontext:property + user {redefines client} Usage (from UML::Classes::Dependencies) Organisation (from MODAF::Operational) OrganisationalResource (from MODAF::Operational) + resource {redefines type} Resource Capability (from MODAF::Capabilities) Class (from UML::CompositeStructures::StructuredClasses) + systemused {redefines supplier} System + fulfilledcapability {redefines client} + capability {redefines class} ResourceForCapability (from MODAF::Capabilities) (from MODAF::Systems) CapabilityFulfilment (from MODAF::Capabilities) {subsets supplier } FieldedCapability (from MODAF::Capabilities) -doctrine:constraint[1..*] + capabilitycontext {redefines role} NetworkedCapabilityConnector (from MODAF::Capabilities) Property (from UML::CompositeStructures::InternalStructures) ConnectorEnd (from UML::CompositeStructures::InternalStructures) NetworkedCapabilityConnectorEnd (from MODAF::Capabilities) {role.type IS System} 2 {subsets end } EffectivityConstrainedItem EffectivityConstraint {subsets constraineditem} + effectivityperiod {redefines specification} TimePeriod Constraint (from UML::Classes::Kernel) Interval (from UML::CommonBehaviors::SimpleTime) Connector (from UML::CompositeStructures::InternalStructures) Figure 5-16: MODAF Meta Model Excerpt for StV Although UML is not the ideal diagramming approach for StV-5, it is still possible to represent the concepts in an StV-5 product using the UML Meta model (with appropriate stereotypes and constraints). The key to understanding how the MODAF Meta model is used for StV-5 (and for StV-3) is the <<FieldedCapability>> stereotype. This is a type of node which is composed of resources (systems and organisations) which satisfy a capability. The assertion that a capability is realised by a <<FieldedCapability>> is via the <<CapabilityFilfilment>> relationship (UML:Usage). <<CapabilityFulfilment>> is subject to dated effectivity, representing the time period during which the <<FieldedCapability>> realises the <<Capability>>. MODAF-M7-022 Version

53 131. A capability or group of capabilities may only be achievable by connecting systems (i.e. "network-enabled capability"). This is represented using <<NetworkedCapabilityConnector>> 132. The model elements used in StV-5 are: a. Capability - A high level user requirement, usually functional. A capability may have performance metrics represented as Physical Properties. Note that some capabilities might be called "Capability Functions" - MODAF does not distinguish between Capability Functions and Capabilities, other than by virtue of their position in a hierarchy, defined by <<CapabilityComposition>> b. CapabilityFulfilment - An assertion that a capability can be met by a <<FieldedCapability>>. c. EffectivityConstrainedItem - An item whose existence is contrained by an <<EffectivityConstraint>> - i.e. something which is valid for a time period. d. EffectivityConstraint - Specifies that the constraineditem has a time-based existence (effectivity) e. FieldedCapability - A combination of organisational aspects (with their competencies) and equipment that combine to provide a capability. A <<FieldedCapability>> must be guided by doctrine which may take the form of <<Standard>> or <<OperationalConstraint>> stereotypes f. NetworkedCapabilityConnector - A connection between systems which contribute to one or more fielded capabilities. The connections may provide a "network enabled capability". g. NetworkedCapabilityConnectorEnd - The connection point for connections in a network enabled capability. The type of the role shall be a <<System>> h. Organisation - A group of persons, associated for a particular purpose. i. OrganisationalResource - Either an organisation, or a post. j. Resource - Something that is able to supply functionality, information or material. k. ResourceForCapability - Relates a <<FieldedCapability>> to a resource that contributes towards achieving the capability - e.g. a type of system operated by an organisation with the appropriate competence. l. System - A coherent combination of physical artefacts, energy and information, assembled for a purpose. m. SystemUsage - Asserts that a <<System>> is used by an <<OrganisationalResource>>. The context for the usage must be specified in terms of the properties typed by the <<OrganisationalResource>> (user context) and the <<System>> (systemused context)- these may be a <<ResourceForNode>> or a <<ResourceForCapability>>. For example, a given type of system may be used by different people or organisations depending on the nature of deployment, or depending on the capability that is being fulfilled. n. TimePeriod - A period of time, defined by start and end dates - sometimes termed an "Epoch" in the MOD. Time periods may overlap. MODAF-M7-022 Version

54 5.6 Capability Function to Operational Activity Mapping (StV-6) StV-6 Product Description Product Definition 133. The Capability Function to Operational Activity Mapping (StV-6) View describes the mapping between capability elements and the operational activities that those capabilities support Product Purpose 134. The StV-6 View provides a bridge between capability analyses using StVs and operational activities analysed using OVs. Specifically, it identifies how operational activities can be performed using various available capability elements Detailed Product Description 135. An StV-6 View shows which elements of military capability may be utilised in support of specific operational activities by means of a mapping matrix. This View is analogous to the SV-5 Operational Activity to System Function Traceability Matrix but provides the interface between Strategic and Operational Views rather than Operational to System Views Figure 5-17 shows an StV-6 extract for a small number of hypothetical land operational tasks. This shows how different capability elements support different stages in the operational process. Prepare estimate Plan collection Manage Intel collection Assess Intel Maintain Recognised Picture Deconflict Battlespace Conduct Fires Battle Damage Assessment ISTAR x x x x x Decision Support x x Effects- Planning x Effects- Engagement x Notes: 1. Decision Support see StV-2 (Capability Functions) 2. Battle Damage Assessment see OV-5 (Operational Activities) Figure 5-17: Example for StV-6 for hypothetical Land Operational Tasks StV-6 UML Representation 137. There is no specific UML diagram that is applicable to the StV-6 View. MODAF-M7-022 Version

55 5.6.3 StV-6 MODAF Meta Model Support OperationalActivity (from MODAF::Operational) Activity (from UML::Activities::BasicActivities) { redefines client} + performedactivity PerformanceEnabler (from MODAF::Capabilities) Usage (from UML::Classes::Dependencies) { redefines supplier} + enablingcapability Capability (from MODAF::Capabilities) Class (from UML::CompositeStructures::StructuredClasses) Figure 5-18: MODAF Meta Model Excerpt for StV The key to modelling an StV-6 product is the use of the <<PerformanceEnabler>> stereotype to link an <<OperationalActivity>> to the <<Capability>> that enables/supports its execution The model elements used in StV-6 are: a. Capability - A high level user requirement, usually functional. A capability may have performance metrics represented as Physical Properties. Note that some capabilities might be called "Capability Functions" - MODAF does not distinguish between Capability Functions and Capabilities, other than by virtue of their position in a hierarchy, defined by <<CapabilityComposition>> b. OperationalActivity - A process carried out by a person or organisation - i.e. not an automated function. c. PerformanceEnabler - The <<PerformanceEnabler>> stereotype links an <<OperationalActivity>> to a <<Capability>> that enables/supports its execution. MODAF-M7-022 Version

56 6 Operational View Products 140. OVs are common to MODAF and DoDAF; OV-1b, OV-1c, and OV-2 however, have been customised to provide for MOD requirements OVs describe the tasks and activities, operational elements, and information exchanges required to conduct operations. There are twelve OV Products: a. High-Level Operational Concept (OV-1a) b. High-Level Operational Concept Description (OV-1b) c. Operational Performance Attributes (OV-1c) d. Operational Node Connectivity Description (OV-2) e. Operational Information Exchange Matrix (OV-3) f. Organisational Relationships Chart (OV-4) g. Operational Activity Model (OV-5) h. Operational Activity Sequence and Timing Descriptions (OV-6a, 6b, and 6c) i. Logical Data Model (OV-7) 142. A description for each of these Views is included below. It should be noted that operational in this context includes business operations as well as military operations. MODAF-M7-022 Version

57 6.1 High Level Operating Concept (OV-1a, 1b, & 1c) OV-1a Product Description Product Definition The High-Level Operational Concept Graphic describes a mission, class of mission, or scenario; and highlights main Operational Nodes (see OV-2 definition) and interesting or unique aspects of operations. It provides a description of the interactions between the subject Architecture and its environment, and between the Architecture and external systems. A textual description accompanying the graphic is crucial. Graphics alone are not sufficient for capturing the necessary Architecture data Product Purpose The purpose of OV-1a is to provide a quick, high-level description of what the Architecture is supposed to do, and how it is supposed to do it. An OV-1a Product can be used to orient and focus detailed discussions. Its main utility is as a facilitator of human communication, and it is intended for presentation to high- level decision makers Detailed Product Description OV-1a consists of a graphical executive summary for a given Architecture with accompanying text. An OV-1a Product identifies the mission/domain covered in the Architecture and the viewpoint reflected in the Architecture. OV-1a will convey, in simple terms, what the Architecture is about and an idea of the players and operations involved The content of an OV-1a Product depends on the scope and intent of the Architecture, but in general it describes the business processes or missions, high-level operations, organisations, and geographical distribution of assets. The Product will frame the operational concept (what happens, who does what, in what order, to accomplish what goal) and highlight interactions to the environment and other external systems. However the content will still be of an executive summary level as other Views allow for more detailed definition of interactions and sequencing During the course of developing an Architecture, several versions of an OV-1a Product may be produced. An initial version may be produced to focus the effort and illustrate its scope. After other Products within the Architecture s scope have been developed and verified, another version of this Product may be produced to reflect adjustments to the scope and other Architecture details that may have been identified as a result of the Architecture development. After the Architecture has been used for its intended purpose and the appropriate analysis has been completed, yet another version may be produced to summarise these findings to present them to high- level decision makers. In other cases, OV- 1a is the last Product to be developed, as it conveys summary information about the whole Architecture for a given scenario OV-1a is the most general of the Architectural Views and the most flexible in format. Because the format is freeform and variable, no template is shown for this View. However, an OV-1a Product usually consists of one or more graphics (or possibly a video-clip), as needed, as well as explanatory text. A graphical example is shown in Figure 6-1. MODAF-M7-022 Version

58 Figure 6-1: Graphical Future Rapid Effect Systems (FRES) OV-1a Representation OV-1a UML Representation 149. There is no specific UML diagram that is applicable to the OV-1a View. If desired, additional, more detailed operational concept diagrams can be constructed using UML use case diagrams. In this situation, several use case diagrams can be constructed, each focusing on a different Architecture mission or operational objective and would then be refined to provide input OV-5. MODAF-M7-022 Version

59 6.1.3 OV-1a MODAF Meta Model Support Class (from UML::Classes::Kernel) Property (from UML::Classes::Kernel) DataType (from UML::Classes::Kernel) PropertyAssignedItem + assigneditem { redefines class} PhysicalProperty -maxvalue:literalspecification[0..1] -minvalue:literalspecification[0..1] + uom {redefines datatype } UnitOfMeasure HighLevelOperationalConcept (from MODAF::Operational) LocationOrEnvironment (from MODAF::Operational) Class (from UML::CompositeStructures::StructuredClasses) + owningscenario {redefines class} Environment (from MODAF::Operational) Location (from MODAF::Operational) -locationdescription:string ItemInConcept (from MODAF::Operational) + iteminscenario {redefines type} ConceptItem (from MODAF::Operational) Node Property (from UML::CompositeStructures::InternalStructures) Resource (discriminator) OrganisationalResource (from MODAF::Operational) In addition to the stereotypes specified in this diagram, all stereotypes from OV-2a may also be shown in an OV-1a. System (from MODAF::Systems) Post (from MODAF::Operational) Organisation (from MODAF::Operational) Figure 6-2: MODAF Meta Model Excerpt for OV-1a 150. OV-1a is difficult to model in M 3. The content of an OV-1a product is not strictly defined, and the product tends to be more of an informative graphic than an architectural model. However, it is clear that the product describes some sort of scenario and the systems, organisations and nodes that have a part in the scenario. Locations are often shown in OV- 1a also In general, the intent is not to be able exchange an OV-1a graphic between tools (other than by transfer of a raster or vector image), but simply to exchange information about the types of architectural element described in the OV-1a The model elements used in OV-1a are: a. ConceptItem - An item which may feature in a high level operational concept. MODAF-M7-022 Version

60 b. Environment - A general specification of the surroundings / scenario in which an operation may take place. Examples of environment would be; "desert", "arctic", "at sea", etc. c. HighLevelOperationalConcept - A generalized model for operations. d. ItemInConcept - A relationship which asserts that a <<ConceptItem>> forms part of the high level operational concept. e. Location - A location anywhere on the earth. The means of describing the location is a string (locationdescription). The information contained in that string is governed by the taxonomy reference e.g. if the GeographicLocation is a GPS reference, the string will contain the GPS coordinates. f. LocationOrEnvironment - Either a specified location, or an environment at/in which operations may be conducted g. Node - A logical entity which creates, consumes or manipulates information. A <<Node>> is a usually grouping of organizations and systems (and other nodes) for a particular purpose. h. Organisation - A group of persons, associated for a particular purpose. i. OrganisationalResource - Either an organisation, or a post. j. PhysicalProperty - A property of something in the physical world, expressed in amounts of a unit of measure. The property may have a required value - either specified by the defaultvalue from uml::property attribute, or the minvalue and maxvalue to specify a required range. k. Post - A post is a type of point of contact or responsible person. Note that this is the type of post - e.g. SO1, Desk Officer, Commander Land Component, etc. l. PropertyAssignedItem - The abstract superclass of all classes which may have physical properties m. Resource - Something that is able to supply functionality, information or material. n. System - A coherent combination of physical artefacts, energy and information, assembled for a purpose. o. UnitOfMeasure - A determinate amount or quantity adopted as a standard of measurement for other amounts or quantities of the same kind OV-1b Product Description Product Definition 153. The Operational Concept Description (OV-1b) Product provides a supplementary textural description that explains and details the scenario contained within the associated High Level Operational Concept Graphic (OV-1a) View. The OV-1b Product will always be developed alongside the associated OV-1a View Product Purpose 154. An OV-1b Product is used to explain and add further detail to the graphical presentation of the scenario shown in the associated OV-1a View. As such it will be prepared alongside the OV-1a and used together they will provide a comprehensive summary of the scenario / use case described within the Operational Views of the Architecture. The OV-1b will also be used to provide a description of the operational context for the scenario / use case under consideration within the other Operational Views. MODAF-M7-022 Version

61 Detailed Product Description 155. The nature and type of description in an OV-1b Product will be very dependant upon the level of detail and maturity in the operational scenario / Architecture being described. An OV-1b Product may contain textual documents, graphical representations, or other material that is deemed appropriate e.g. video clips. An example of an extract from an OV-1b is shown in Figure 6-3 in this case purely in textural form Regardless of the method of representation it is imperative that the information in the View is consistent with the other OV Views, and when the OV-1b is updated or modified these changes are cascaded throughout the Architecture. ISTAR information is currently provided by the SPECS system, the LOOKER UAV system and by the NEMESIS system. SPECS is an Operational level asset, and communicates via a data link to its dedicated base station. LOOKER is a tactical UAV system that can transmit real-time video footage directly to either Fighting Patrols or to the Brigade HQ. NEMESIS is a strategic asset that has considerable on-board processing capability, enabling the data to be exploited during flight. The resultant information can be communicated either by Satellite communications or directly to a receiver based on board a Naval vessel OV-1b UML Representation Figure Extract from an OV-1b Example 157. There is no specific UML diagram that is applicable to the OV-1b View OV-1b MODAF Meta Model Support HighLevelOperationalConcept (from MODAF::Operational) + concept {redefines annotatedelement } ConceptDescription (from MODAF::Operational) Class (from UML::CompositeStructures::StructuredClasses) Comment (from UML::Classes::Kernel) Figure 6-4: MODAF Meta Model Excerpt for OV-1b 158. OV-1b adds a textual description of the high level concept of operations graphic shown in OV-1a by using a stereotype of Comment - <<ConceptDescription>>. a. The model elements used in OV-1b are: MODAF-M7-022 Version

62 b. ConceptDescription - A textual representation of a <<HighLevelOperationalConcept>> c. HighLevelOperationalConcept - A generalized model for operations OV-1c Product Description Product Definition 159. An Operational Performance Attributes (OV-1c) Product provides detail of the operational performance attributes associated with the scenario / use case represented in the High Level Operating Concept Graphic (OV-1) Product Purpose 160. An OV-1c Product is used to specify quantifiable attributes and values within the scenario / use case represented in the OV-1 View. The values expressed define the performance of specific or multiple capability elements, and can be represented as either single values, or a range of values across a defined timescale Detailed Product Description 161. The performance of an operational scenario / use case can be measured in a variety of different ways depending upon the scenario context, the Capabilities needed to satisfy the requirement, and the Systems deployed to provide the required Capabilities. Possible attributes may include Operational tempo, Accuracy of targeting, Fratricide rate, etc. Furthermore, the attributes may be able to be linked to a specific system, or may only be able to be considered as an emergent property e.g. dependent upon all of the elements that are interacting within the scenario, rather than an attribute of the individual elements The attributes and values that are specified may be as single values e.g. the target engagement process is to be concluded in a maximum time of 25 minutes, or may be used to represent trends or targets that are expected to be achieved. This type of attribute would be represented by a number of values for various points in time or periods of time. An example of this type of OV-1c Product is shown in Figure 6-5: Attribute Measure Value As - Is Epoch 1 Epoch 2 Target Operational Tempo Rate of Advance for an Armoured Brigade against light resistance 20 km/day 40 km/day 60 km/day 80 km/day Synchronisation of Effects Sortie Rate Simultaneous rounds on impact delivered by an Arty Bty Period to refuel and rearm an aircraft 30 rounds 40 rounds 60 rounds 100 rounds 4 hours 3 hours 2 hours 1 hours Figure 6-5: Example of an OV-1c View MODAF-M7-022 Version

63 6.1.8 OV-1c UML Representation 163. There is no specific UML diagram that is applicable to the OV-1c View OV-1c MODAF Meta Model Support Class (from UML::Classes::Kernel) PropertyAssignedItem HighLevelOperationalConcept (from MODAF::Operational) + assigneditem {redefines class} Property (from UML::Classes::Kernel) PhysicalProperty -maxvalue:literalspecification[0..1] -minvalue:literalspecification[0..1] + uom { redefines datatype } DataType (from UML::Classes::Kernel) UnitOfMeasure Figure 6-6: MODAF Meta Model Excerpt for OV1-c 164. OV-1c adds properties to the high level concept of operations from OV-1a by using the <<PhysicalProperty>> stereotype The model elements used in OV-1c are: a. HighLevelOperationalConcept - A generalized model for operations. b. PhysicalProperty - A property of something in the physical world, expressed in amounts of a unit of measure. The property may have a required value - either specified by the defaultvalue from uml::property attribute, or the minvalue and maxvalue to specify a required range. c. PropertyAssignedItem - The abstract superclass of all classes which may have physical properties d. UnitOfMeasure - A determinate amount or quantity adopted as a standard of measurement for other amounts or quantities of the same kind. MODAF-M7-022 Version

64 6.2 Operational Node Connectivity Description (OV-2) OV-2 Product Description Product Definition 166. The Operational Node Connectivity Specification (OV-2) depicts Operational Nodes with Needlines between those Nodes that indicate a need to exchange information. The OV- 2 may also show the location (geographic, or Platform) of Operational Nodes, and may optionally be annotated to show flows of materiel or people between Nodes. The Operational Nodes shown in an OV-2 Product may be internal to the Architecture, or external Nodes that communicate with those internal Nodes Product Purpose 167. The purpose of an OV-2 Product is to define a logical Network of information flows. The Nodes on the logical Network need not correspond to specific organisations, systems or locations, allowing Information Exchange Requirements (IERs) to be established without prescribing the way that the information exchange is handled. OV-2 is intended to track the need to exchange information from specific Operational Nodes (that play a key role in the Architecture) to others. OV-2 does not depict the physical connectivity between the Nodes. The nodal Network established in an OV-2 Product often acts as the backbone onto which architectural elements may be overlaid e.g. an SV-1 Product can show which systems provide the necessary capability at each Node Detailed Product Description 168. The main features of this Product are the Operational Nodes, and the location (or type of location / environment) where the Nodes are deployed, and the Needlines between the Nodes that indicate a need to exchange or share information. An OV-2 Product indicates the key players and the interactions necessary to conduct the corresponding operational activities of OV Operational Nodes 169. An Operational Node is an element of the operational Architecture that produces, consumes, or processes information. What constitutes an Operational Node can vary among Architectures, including, but not limited to; representing an operational/human role (e.g., Air Operations Commander), an organisation (e.g., The Ministry of Defence) or organisation type, i.e., a logical or functional grouping (e.g., Logistics Node, Intelligence Node), and so on. The notion of Operational Node will also vary depending on the level of detail addressed by the Architecture effort. Items that are Operational Nodes may in reality be System Nodes as well, and such duality is permissible for example, the battleship (System Node) which acts as the operational command (Operational Node) may be modelled as one Node. For this reason, the M 3 defines only the concept of <<Node>> rather than restricting the user to specifying a system or Operational Node. The aim of an OV-2 Product is to record the operational characteristics of the Node Needlines and Information Exchanges 170. A Needline documents the requirement to exchange or share information between Nodes. The Needline does not indicate how the transfer is implemented. For example, if information is produced at Node A, is simply routed through Node B, and is used at Node C, then Node B would not be shown on the OV-2 diagram the Needline would go from Node A to Node C. OV-2 is not a communications link or communications network diagram. The MODAF-M7-022 Version

65 supporting system implementation (or what systems Nodes or systems are used to carry the information exchanges) is shown in the Systems Interface Description (SV-1). Furthermore, the systems-equivalent to a Needline is the interface line depicted in SV-1. The actual implementation of an interface may take more than one form and is documented in a Systems Communications Description (SV-2). Therefore, a single Needline shown in the OV may translate into multiple interfaces in SV-1 and multiple physical links in SV-2. This might be because several hops between are required to fulfil the Needline, because the Needline carries multiple information exchanges which are implemented differently, or because redundancy is needed in the physical links Needlines are represented by arrows (indicating the direction of information flow) and are annotated with a diagram-unique identifier and a phrase that is descriptive of the principal types of information exchanged it may be convenient to present these phrases in a key to the diagram to prevent cluttering. It is important to note that the arrows (with identifiers) on the diagram represent Needlines only. This means that each arrow indicates only that there is a need for some kind of information transfer between the two connected Nodes There is a one-to-many relationship from Needlines to information exchanges (e.g., a single Needline in OV-2 represents multiple individual information exchanges). The mapping of the information exchanges to the Needlines of OV-2 occurs in the Operational Information Exchange Matrix (OV-3). For example, OV-2 may list Situation Report as a descriptive name for a Needline between two Operational Nodes. In this example, the Needline represents a number of information exchanges, consisting of various types of reports (information elements), and their attributes (such as periodicity and timeliness) that are associated with the Situation Report Needline. The identity of the individual information elements and their attributes are documented in OV An OV-2 Product will also illustrate needs to exchange information between Operational Nodes and external Nodes (i.e., Operational Nodes that are not strictly within the scope of the subject Architecture but which interface to it either as important sources of information required by Nodes within the Architecture or important destinations for information provided by Nodes within the Architecture) Flows of Material and People 174. In addition to Needlines, it may be useful to overlay contextual information about how the Nodes interact at a physical level. This information is not directly related to the Architecture, but may help provide context about the Nodes. This is achieved by overlaying the flows on the diagram using a notation that is clearly distinct from Needlines (which only represent the requirement to exchange information between Nodes). People and Materiel flows are purely informative and play no part in the Architecture itself the only other Product that may display these flows is an OV-1a. An example overlay is shown in Figure Operational Activities 175. The operational activities (from the OV-5 Operational Activity Model) performed by a given Node may be listed on the graphic, if space permits. OV-2, in effect, turns OV-5 inside out, focusing first-order on the Operational Nodes and second-order on the activities. OV-5, on the other hand, places first-order attention on operational activities and only second-order attention on Nodes, which can be shown as annotations or swim-lanes on the activities. In developing an Architecture, OV-2 and OV-5 are often the starting points Platform & Geographic Location 176. An OV-2 Product may show the location of each operational node, if the location is known or knowable. The location may be specified geographically, and this in turn may be a MODAF-M7-022 Version

66 specific geographic location (e.g. RAF Wyton) or a type of location or environment (e.g. behind enemy lines). Note that this is distinct from the concept of a Platform (e.g. a warship), which would be represented as a Node onto which Operational Nodes may be overlaid Representation of the Product 177. For complex Architectures, OV-2 may consist of multiple graphics. There are at least two different ways to decompose OV-2. One method involves using multiple levels of abstraction and decomposing the Nodes. Another method involves restricting the Nodes and Needlines on any given graphic to those associated with a subset of operational activities. Both of these methods are valid and can be used together Nodes are independent of materiel considerations; indeed, they exist to fulfil the missions of the enterprise and to perform its tasks and activities (business processes, procedures, and operational functions). Use of Nodes and Needlines supports analysis and design by separating business process modelling and information requirements from the materiel solutions that support them. Similarly, tasks and activities are organised, and communities of interest are defined to suit the mission and process requirements. However, an OV often has materiel constraints and requirements that must be addressed. In reality the Node being examined may be a Platform or system and the OV-2 diagram just provides the operational View of that node. Thus where appropriate, System or Physical Nodes that constitute the location of an Operational Node shall augment the description of an operational node. These are often taken as recommendations or boundaries for further SV details. Figure 6-7 and Figure 6-8 show example OV-2 diagrams. Node Carrier Battle Group Location Ruritania Node Sea Ops Control 1 Node Land Ops Control 2 Node Artillery Node SF Squadron Node Stores Ship 3 Node Forward Base 6 Node Spot Team 5 Location UK Node Ammo Stores Ammunition Supply: MaterielFlow Needlines: 1 Request Target Recon 2 Request Bombardment 3 Request Target Recon 4 HUMINT 5 Supplies Request 6 Recon Report 7 Heavy Munitions Request 8 Light Munitions Request Figure 6-7: Imaginary OV-2 Example MODAF-M7-022 Version

67 Figure 6-8: Example OV-2 from US Navy 179. Service-provider Architectures also use a type of logical node. One purpose of a service provider Architecture can be to communicate an external view of the available services to potential subscriber communities. In this situation, the service provider s OV-2 (and OV-3) can use generic representations of the subscriber environments it supports and, potentially, of the service provider facilities as well For the service provider, Needlines may focus on the characteristics of the service provided or on a generic type of information to be exchanged and not on the exact type or critical attributes of the actual information exchanged. What is represented depends on the type of service being provided. For example, a communications service provider will describe MODAF-M7-022 Version

68 Needlines in terms of the type of information to be transferred, with what reliability or priority and security features. A human resources (HR) services provider will describe Needlines in terms of the complete set of HR information produced or consumed, but any given subscriber may only deal with a subset of this information. Figure 6-9 is a notional example of service providers and subscribers. Figure 6-9: Example OV-2 for Service Provision 181. Subscribers can use information from the service provider s OV-2 to build the portions of their own OV-2 that include use of services from the service provider. The subscribers fill in the blanks or make specific the relevant generic portions of the service provider s OV-2. Note: At the time of publication, the MOD approach to service oriented Architectures had not been finalised. A later release (or addendum) to the Handbook will provide clearer guidance on how to represent services in MODAF Products OV-2 UML Representation 182. OV-2 may be expressed as a UML class diagram, using the stereotypes defined in the M 3. Figure 6-10 shows an example OV-2 diagram in UML. <<DiagramCompositeClass>> MyOperationalNodeConnectivityDiagram <<Node>> CBG:Carrier Battle Group <<Location>> Ruritania:Country <<Node>> Sea Ops Control : Ops Control Node <<Needline>> 7 <<Needline>> 1 <<Needline>> 8 <<Node>> Land Ops Control : Ops Control Node <<Needline>> 2 <<Node>> Artillery : Bombardment Node <<Needline>> 4 <<Node>> SF Squadron : Land Cell <<Node>> Stores Ship : Storage Node 3 <<Needline>> <<Node>> Forward Base : Deployed Ops Base <<Needline>> 6 <<Node>> Spot Team : Land Cell <<Needline>> 5 <<Location>> UK:Country Ammunition Supply: MaterielFlow <<Node>> Ammo Stores:Storage Node <<NodeConnector>> Figure 6-10: Example UML for OV It should be noted that the M 3 uses a generic <<Node>> stereotype to cover both systems and Operational Nodes. MODAF-M7-022 Version

69 6.2.3 OV-2 MODAF Meta Model Support Location (from MODAF::Operational) Environment (from MODAF::Operational) -locationdescription:string Class (from UML::CompositeStructures::StructuredClasses) DiagramCompositeClass LocationOrEnvironment (from MODAF::Operational) + locatedat { redefines class} NodeLocation (from MODAF::Operational) ConnectorEnd Activity (from UML::Activities::BasicActivities) + node { redefines type} (from UML::CompositeStructures::InternalStructures) OperationalActivity (from MODAF::Operational) Node + parent {redefines class} + child {redefines type} NodeAssemblyUsage NestedConnectorEnd -propertypath:property[2..*ordered] ActivityConductedAtNode (from MODAF::Operational) -nodeusagecontext:property + activityconducted { redefines supplier} Dependency (from UML::Classes::Dependencies) + conductedat {redefines client} + owningnode {redefines class } Property (from UML::CompositeStructures::InternalStructures) + fromnode { subsets memberend[2]} + tonode { subsets memberend[2]} NodeConnectionType AssociationClass (from UML::Classes::AssociationClasses) + connectioncontext {redefines role} { subsets type} NodeConnectorEnd { subsets end} 2 ResourceForCapability (from MODAF::Capabilities) ResourceForNode -resourceisnode:boolean Needline (from MODAF::Operational) -needlinenumber:int NodeConnector + capability {redefines class} FieldedCapability (from MODAF::Capabilities) -doctrine:constraint[1..*] + resource { redefines type} Resource + deployedresource { redefines type} + supportingneedlines * {redefines realizingconnector} 1..* + supportedexchanges InformationExchange (from MODAF::Operational) Connector (from UML::CompositeStructures::InternalStructures) -requirementtext:string (discriminator) Post (from MODAF::Operational) OrganisationalResource (from MODAF::Operational) Organisation (from MODAF::Operational) InformationFlow (from UML::AuxiliaryConstructs::InformationFlows) Figure 6-11: MODAF Meta Model Excerpt for OV The key stereotype in OV-2 is <<Node>>. Nodes may be assembled using a UML composite class diagram (using <<NodeAssemblyUsage>> to relate the parent node to its MODAF-M7-022 Version

70 children. Similarly, nodes may be positioned at a location using the composite class technique (via <<NodeLocation>>) Connections between nodes are described using <<NodeConnector>> (for flows of materiel or personnel) and <<Needline>> for flows of information. If connections between two top-level nodes (i.e. the top-most classes in a composite class model) then <<DiagramCompositeClass>> should be used as the top-level class Modelling the OperationalActivities which take place at Nodes is achieved using the <<ActivityConductedAtNode>> stereotype. In most cases, the same classes of node will conduct the same activities. However, if an activity is peculiar to one usage of a Node, the nodeusagecontext attribute on <<ActivityConductedAtNode>> indicates the property which owns the usage of the class Finally, it is possible to overlay organisations and posts on the model using <<ResourceForNode>> which again employs the composite class technique. To provide a tight linkage with the Strategic Viewpoint, it is possible to deploy a <<FieldedCapability>> to a node - again using the <<ResourceForNode>> property. The use of <<FieldedCapability>> is the preferred way to deploy resources to nodes, however it is recognised that the capability approach is not always appropriate for this task - e.g. the required deployment may not be represented by a given capability - hence resources may be deployed directly to nodes The model elements used in OV-2 are: a. ActivityConductedAtNode - Asserts that an <<OperationalActivity>> is conducted at a <<Node>>. Should the same type of node be used in different contexts in the architecture, and the activity is conducted under only one of the contexts, that context is provided by the nodeusagecontext property. b. DiagramCompositeClass - DiagramCompositeClass is used as a top-level class for a composite class diagram when it is not possible to use an architectural element as the toplevel class. This usually arises when connections are required between two classes which are at the top level - which is not generally possible. In such a case, the two top-level architectural elements would be properties of the DiagramCompositeClass, enabling connections to be made between the properties. c. Environment - A general specification of the surroundings / scenario in which an operation may take place. Examples of environment would be; "desert", "arctic", "at sea", etc. d. FieldedCapability - A combination of organisational aspects (with their competencies) and equipment that combine to provide a capability. A <<FieldedCapability>> must be guided by doctrine which may take the form of <<Standard>> or <<OperationalConstraint>> stereotypes e. InformationExchange - A specification of the information that is to be exchanged. f. Location - A location anywhere on the earth. The means of describing the location is a string (locationdescription). The information contained in that string is governed by the taxonomy reference e.g. if the GeographicLocation is a GPS reference, the string will contain the GPS coordinates. g. LocationOrEnvironment - Either a specified location, or an environment at/in which operations may be conducted h. Needline - A relationship specifying the need to exchange information between nodes. The needline does not indicate how the transfer is implemented. MODAF-M7-022 Version

71 i. NestedConnectorEnd - To maintain compatibility with the SysML standard ( MODAF has tried to re-use as many of the SysML stereotypes as possible. j. Node - A logical entity which creates, consumes or manipulates information. A <<Node>> is a usually grouping of organizations and systems (and other nodes) for a particular purpose. k. NodeAssemblyUsage - Used to link a parent node to its sub-nodes. Only NodeAssemblyUsage may be used to represent a node-subnode relationship. l. NodeConnectionType - A type of connection between nodes. In most cases this is not required - NodeConnectors and Needlines need not be typed m. NodeConnector - Asserts that a connection exists between two parts in a node composite structure model. n. NodeConnectorEnd - The end of a connector between nodes. o. NodeLocation - Relates a node to a location to assert that the node is situated at that location. p. OperationalActivity - A process carried out by a person or organisation - i.e. not an automated function. q. Organisation - A group of persons, associated for a particular purpose. r. OrganisationalResource - Either an organisation, or a post. s. Post - A post is a type of point of contact or responsible person. Note that this is the type of post - e.g. SO1, Desk Officer, Commander Land Component, etc. t. Resource - Something that is able to supply functionality, information or material. u. ResourceForCapability - Relates a <<FieldedCapability>> to a resource that contributes towards achieving the capability - e.g. a type of system operated by an organisation with the appropriate competence. v. ResourceForNode - An assertion that a resource is provided to a node. If resourceisnode is true then the resource itself is the node - e.g. an "Aircraft Carrier" <<System>> could be the "Maritime Ops Control" <<Node>>, or a "Spot Team" <<Organisation>> could be the "Forward Observation" <<Node>> MODAF-M7-022 Version

72 6.3 Operational Information Exchange Matrix (OV-3) OV-3 Product Description Product Definition The Operational Information Exchange Matrix details information exchanges and identifies who exchanges what information, with whom, why the information is necessary, and how the information exchange must occur. There is not always a one-to-one mapping of OV-3 information exchanges to OV-2 Needlines; rather, many individual information exchanges may be associated with one Needline Product Purpose Information exchanges express the relationship across the three basic Architecture data elements of an OV (Operational activities, Operational Nodes, and information flow) with a focus on the specific aspects of the information flow and the information content. The aspects of the information exchange that are crucial to the operational mission will be tracked as attributes in OV-3. For example, if the subject Architecture concerns tactical battlefield targeting, then the timeliness of the enemy target information is a significant attribute of the information exchange Detailed Product Description An OV-3 Product identifies information elements and relevant attributes of the information exchange and associates the exchange to the producing and consuming Operational Nodes and activities and to the Needline that the exchange satisfies An information exchange is an act of exchanging information between two distinct Operational Nodes and the characteristics of the act, including the information element that needs to be exchanged and the attributes associated with the information element (e.g., Scope), as well as attributes associated with the exchange (e.g., Transaction Type). A Needline represents one or more information exchanges An information element is a formalised representation of information subject to an operational process (e.g., the information content that is required to be exchanged between Nodes). In contrast an information exchange is composed of the Needline, the information element, and other attributes such as Information Assurance attributes. The specific attributes of the information elements included are dependent on the objectives of the specific Architecture effort and include the information scope, accuracy, and language. An information element may be used in one or more information exchanges The specific mission/scenario and the related task can be noted as an attribute of the information exchange. The emphasis in this Product is on the logical and operational characteristics of the information. It is important to note that OV-3 is not intended to be an exhaustive listing of all the details contained in every information exchange of every Operational Node associated with the Architecture in question. Nor will the production of such a matrix be considered sufficient to replace an integrated Architecture development effort. Rather, this Product is intended to capture the most important aspects of selected information exchanges Two representative formats for the OV-3 Operational Information Exchange Matrix are shown in Figure 6-12 and Figure 6-13 respectively. MODAF-M7-022 Version

73 Figure 6-12: Joint Force Targeting (from DoDAF Deskbook) Figure 6-13: Notional Strike Mission (from the DoDAF Deskbook) 196. In Figure 6-12, each information exchange is associated with the Needline it helps satisfy. There may be many individual exchanges that collectively satisfy a single Needline. It should also be noted that each information element exchanged is related to the leaf Operational Activity (from the Operational Activity Model [OV-5]) that produces or consumes it. MODAF-M7-022 Version

74 197. There may not be a one-to-one correlation between information elements listed in the matrix and the information inputs and outputs that connect activities in a related OV-5. Information inputs and outputs between activities performed at the same Node (i.e., not associated with a Needline on OV-2) will not show in OV-3. Information inputs and outputs between activities for some levels of Operational Activity decomposition may be at a higher level of abstraction than the information elements in the matrix. In this case, multiple information exchanges will map to a single Operational Activity input or output. Similarly, the information inputs and outputs between activities at a low level of activity decomposition may be at a higher level of detail than the information exchanges in the matrix, and multiple information inputs and outputs may map to a single information exchange. Information elements trace to the entities in a Logical Data Model (OV-7) OV-3 UML Representation 198. There is no specific UML diagram that is applicable to the OV-3 View OV-3 MODAF Meta Model Support Connector (from UML::CompositeStructures::InternalStructures) InformationFlow (from UML::AuxiliaryConstructs::InformationFlows) NodeConnector + supportedexchanges 1..* InformationExchange (from MODAF::Operational) -requirementtext:string Needline (from MODAF::Operational) -needlinenumber:int + * supportingneedlines {redefines realizingconnector} {redefines conveyed} + conveyedelement InformationItem (from UML::AuxiliaryConstructs::InformationFlows) InformationElement + definedelement {redefines client} InformationDescriptor + definition {redefines supplier} Realization (from UML::Classes::Dependencies) DefinitionOfInfoElement Entity DataModel Attribute Class (from UML::Classes::Kernel) Package (from UML::Classes::Kernel) Property (from UML::Classes::Kernel) Figure 6-14: MODAF Meta Model Excerpt for OV-3 MODAF-M7-022 Version

75 199. The needlines described in OV-2 are expanded upon in OV-3. Needlines support one or more <<InformationExchange>> information flows. Each InformationExchange conveys one or more UML::InformationItems, stereotyped as <<InformationElement>> Although it is not mandated in an OV-3 product, it is often necessary to describe the data model elements (from OV-7) that define the structure of the <<InformationElement>> items that are exchanged. This is achieved using a <<DefinitionOfInfoElement>> stereotype The model elements used in OV-3 are: a. Attribute - A property of an entity. b. DataModel - A structural specification of data, showing classifications of data elements and relationships between them. c. DefinitionOfInfoElement - Relates an <<InformationElement>> to the information descriptor (i.e. a data model definition or aspect) which defines it. d. Entity - A definition (type) of an item of interest. e. InformationDescriptor - A data model element that can be used to define an item of information (InformationElement) f. InformationElement - a formalized representation of information subject to an operational process g. InformationExchange - A specification of the information that is to be exchanged. h. Needline - A relationship specifying the need to exchange information between nodes. The needline does not indicate how the transfer is implemented. i. NodeConnector - Asserts that a connection exists between two parts in a node composite structure model. MODAF-M7-022 Version

76 6.4 Organisational Relationships Chart (OV-4) OV-4 Product Description Product Definition 202. The Organisational Relationships Chart illustrates the command structure or relationships (as opposed to relationships with respect to a business process flow) among human roles, organisations, or organisation types that are the key players in an Architecture Product Purpose 203. An OV-4 Product clarifies the various relationships that can exist between organisations and sub-organisations within the Architecture and between internal and external organisations Detailed Product Description 204. An OV-4 Product illustrates the relationships between organisations in an Architecture. There can be many types of inter-organisational relationships such as supervisory reporting, Command and Control (C2) relationships, collaboration and so on. The more commonly used types are defined in the MODAF Taxonomy. Architects may find a need for types of organisational relationship which are not defined in the Taxonomy, depending on the purpose of the Architecture. Architects are free to define any kinds of relationships necessary and important within their Architecture to support the goals of the Architecture. In such cases architects will record and define these additional relationship classifications in AV An OV-4 Product illustrates the relationships among organisations or organisation types that are the key players in an Architecture. These key players may be deployed to the Operational Nodes of an OV-2, which contain added detail on how the key players interact together in order to conduct their corresponding operational activities of OV Human roles whose skills are needed to perform the operational activities or business processes described in the Architecture may also be defined in OV-4. The corresponding operational activities will be decomposed to a degree that allows them to be correlated to specific human roles within organisations. In addition, and specifically in the case of target Architectures, human roles that do not reflect a specific supervisory reporting, C2, or coordination organisational structure may be used in OV-4. In this case, OV-4 may be developed using strictly human roles that are the key players in an Architecture Organisational relationships are important to depict in an OV (for a current Architecture), because they can illustrate fundamental human roles (e.g., who or what type of skill is needed to conduct operational activities) as well as management relationships (e.g., command structure or relationship to other key players). Also, organisational relationships may influence how the Operational Nodes in an OV-2 are connected. A template is shown in Figure 6-15, and the UML model in Figure 6-16 provides a fictitious populated example As the template illustrates, boxes can show hierarchies of organisations, and different colours or styles of connecting lines can indicate various types of relationships among the organisations. MODAF-M7-022 Version

77 Figure 6-15: Organisational Relationships Chart (OV-4) Template OV-4 UML Representation 209. A class diagram (using the actor icon) may be used to represent Organisational Relationships Charts. Class relationship notation can be used to show relationships among organisations. Figure 6-16 illustrates such a diagram. <<Organisation>> GovernmentMinistry <<Organisation>> CommercialCompany Typical :GovernmentAgency [1..*] :ProjectTeam [1..*] :ProjectLeader :Department [1..*] :DepartmentHead <<ActualOrganisation>> MOD:GovernmentMinistry <<ActualOrganisation>> UAVS-R-US:CommercialCompany <<ActualOrganisation>> DLO:GovernmentAgency <<ActualOrganisation>> DPA:GovernmentAgency <<ActualOrganisation>> R&D:Department <<ActualOrganisation>> HR:Department Specific <<ActualOrganisation>> ArcherIPT:ProjectTeam <<ActualOrganisation>> WatchMakerIPT: ProjectTeam seconded staff seconded staff <<ActualOrganisation>> Manufacturing:Department <<ActualOrganisation>> Sales:Department account management <<ActualPost>> ArcherIPTLeader: ProjectLeader <<ActualOrganisation>> MilitarySales:Department <<ActualOrganisation>> Non-GovSales:Department Figure 6-16: UML Organisational Relationships Chart, OV-4 MODAF-M7-022 Version

78 6.4.3 OV-4 MODAF Meta Model Support Slot (from UML::Classes::Kernel) ActualRoleInOrganisation (from MODAF::Operational) + roletype {redefines definingfeature} RoleInOrganisation (from MODAF::Operational) {aggregation = composite} TypicalOrganisationRelationship (from MODAF::Operational) {fromorgrole.class :=: fromorg,toorgrole.type :=: toorg} -fromorgrole:property[0..1] -toorgrole:property[0..1] Usage (from UML::Classes::Dependencies) + roleprovider {redefines type} + organisationowningrole {redefines class} OrganisationalResource (from MODAF::Operational) (discriminator) + toorg { redefines client} Organisation (from MODAF::Operational) InstanceSpecification (from UML::Classes::Kernel) + fromorg { redefines supplier} + organisationtype {redefines classifier} ActualOrganisation ActualOrganisationRelationship (from MODAF::Operational) (from MODAF::Operational) -typicalrelationship:usage[0..1] {redefines owninginstance} + fromorg ActualOrganisationalResource {redefines supplier} (from MODAF::Operational) + toorg {redefines client} Resource Post (from MODAF::Operational) + posttype {redefines classifier} ActualPost (from MODAF::Operational) Property (from UML::CompositeStructures::InternalStructures) Class (from UML::CompositeStructures::StructuredClasses) DiagramCompositeClass Figure 6-17: MODAF Meta Model Excerpt for OV OV-4 products may shown types of organisations and the typical structure of those organisations. This is represented as a composite class model. OV-4 products may also show actual, specific organisations (e.g. "The UK Ministry of Defence") and their structure, represented by instances and slots. In both the typical and specific cases, it is possible to overlay organisational relationships (Usages) which denote relationships between organisational elements that are not structural (e.g. a customer-supplier relationship) Two key elements may be shown in an OV-4; organisations and posts (as classes and as instances). Typical organisational structure is denoted with a UML composite structure diagram - with parts being typed as either organisations or posts - the property that represents the parts is stereotyped as <<RoleInOrganisation>>. Relationships between organisations which are not composite (e.g. contract relationships, supplier / consumer relationships, etc.) are modelled using a stereotype of Usage; <<TypicalOrganisationRelationship>>, and the type of relationship is indicated by a reference to a MODAF Taxonomy element. Note that the <<TypicalOrganisationRelationship>> relates two <<RoleInOrganisation>> properties - this allows relationships between specific usages of types of organisation to be modelled Note that individual people are not modelled in MODAF The model elements used in OV-4 are: a. ActualOrganisation - An actual specific organisation, an instance of an organisation class - e.g. "The UK Ministry of Defence" b. ActualOrganisationalResource - In instance of either an organisation or a post. MODAF-M7-022 Version

79 c. ActualOrganisationRelationship - A relationship between two actual specific parts of an organisation. d. ActualPost - An actual, specific post, an instance of a Post class - e.g. "Bowman IPT Leader" e. ActualRoleInOrganisation - Relates an actual specific organisation to an actual specific organisational resource that fulfils a role in that organisation. f. DiagramCompositeClass - DiagramCompositeClass is used as a top-level class for a composite class diagram when it is not possible to use an architectural element as the toplevel class. This usually arises when connections are required between two classes which are at the top level - which is not generally possible. In such a case, the two top-level architectural elements would be properties of the DiagramCompositeClass, enabling connections to be made between the properties. g. Organisation - A group of persons, associated for a particular purpose. h. OrganisationalResource - Either an organisation, or a post. i. Post - A post is a type of point of contact or responsible person. Note that this is the type of post - e.g. SO1, Desk Officer, Commander Land Component, etc. j. Resource - Something that is able to supply functionality, information or material. k. RoleInOrganisation - Defines a role in an organisation which is fulfilled by a post or by a sub-ordinate organisation. The role may or may not be fulfilled (i.e. roleprovider is null) - e.g. it may be a vacant post l. TypicalOrganisationRelationship - Asserts that two <<Organisation>> types typically are related - for example, one may assert that manufacturers and parts suppliers are typically related. It is also possible to specify that the relationship only exists in a certain context (i.e. when the organisations play a certain role). For example, a company's design department may second staff to a government department when both those departments are in the same integrated project team. This is achieved by setting the fromorgrole and toorgrole attributes to properties that are stereotyped as <<RoleInOrganisation>>. MODAF-M7-022 Version

80 6.5 Operational Activity Model (OV-5) OV-5 Product Description Product Definition 214. The Operational Activity Model describes the operations that are normally conducted in the course of achieving a mission or a business goal. It describes operational activities (or tasks), Input/Output (I/O) flows between activities, and I/O flows to/from activities that are outside the scope of the Architecture Product Purpose 215. OV-5 can be used to: a. Clearly delineate lines of responsibility for activities when coupled with OV-2; b. Uncover unnecessary Operational Activity redundancy; c. Make decisions about streamlining, combining, or omitting activities; d. Define or flag issues, opportunities, or operational activities and their interactions (information flows among the activities) that need to be scrutinised further; and e. Provide a necessary foundation for depicting activity sequencing and timing in OV-6a, OV-6b, and OV-6c Detailed Product Description 216. An OV-5 Product describes operational activities (or tasks), I/O flows between activities, and I/O flows to/from activities that originate or terminate outside the scope of the Architecture MODAF does not endorse a specific modelling methodology. However, if the Integration Definition for Function Modelling (IDEF0) 10 method used, the activities also show controls (factors that affect the way that the activity is performed) and may show mechanisms (the resources, including Operational Nodes, that perform the activity). While some may illustrate corresponding systems as mechanisms in this model, the reader is cautioned that the introduction of system data early in the development of the OV may result in limiting system design and implementation decisions I/Os of operational activities relate to information elements of OV-3 and are further characterised by the information exchange attributes described in OV-3. I/Os that are produced or consumed by leaf operational activities that cross Operational Node boundaries are carried by Needlines of OV-2. In addition, operational activities can be annotated (e.g., via the mechanism arrow in an IDEF0 diagram) with the corresponding Operational Node from OV Annotations to the activities may also identify the costs (actual or estimated) associated with performing each activity. The business rules that govern the performance of the activities can also be keyed to each activity. (Business rules are described in OV-6a.) Annotations to OV-5s can further the purposes of the description by adding specific attributes of exchanged information, which can later be used in OV Integration Definition for Function Modelling (IDEF0) method US FIPS 183, 1993 MODAF-M7-022 Version

81 220. The activities described in an OV-5 may correspond to capabilities. StV-6 describes the mapping from capabilities to the operational activities that they support OV-5 graphic(s) may include a hierarchy chart of the activities covered in the model. A hierarchy chart helps provide an overall picture of the activities involved and a quick reference for navigating the OV-5 I/O flow model OV-5 is frequently used in conjunction with a process flow model (such as an IDEF3 model, or a UML sequence diagram) that describes the sequence and other attributes (e.g., timing) of the activities. A process flow model further captures precedence and causality relations between situations and events by providing a structured method for expressing knowledge about how a process or organisation works. In addition, a process flow model may be annotated with the names of the Operational Nodes responsible for conducting those activities. A process flow model may be described in OV-6c The decomposition levels and the amount of detail shown on OV-5 will be aligned with the Operational Nodes that are responsible for conducting the operational activities (shown on corresponding OV-2 Products). It is important to note that OV-5 is intended to be only as exhaustive as necessary to attain the objectives for the Architecture as stated in AV-1. Figure 6-18 depicts templates for the Operational Activity Hierarchy Chart and one level of a process flow OV-5. Figure 6-18: Operational Activity Hierarchy Chart and Operational Activity Diagram (OV-5) Templates 224. Figure 6-19 is a process-oriented OV-5 template showing how some additional Architecture data may be added as annotations to the original template. For example, activities may be annotated with information concerning the Operational Nodes that conduct them, the materiel that supports them, the cost of conducting the activity, and so forth. (The types of additional Architecture data are notional.) Figure 6-19: Operational Activity Model (OV-5) Template with Notional Annotations MODAF-M7-022 Version

82 6.5.2 OV-5 UML Representation 225. UML activity diagrams are useful for representing OV-5 Products. A UML activity diagram with swim-lanes representing nodes is shown in Figure 6-20, and Figure 6-21 shows the actions that make up on of the activities from Figure <<Node>> Land Ops Control : OperationalNode <<OperationalActivityAction>> Request Target Strike Target Location <<Node>> Forward Base : OperationalNode <<OperationalActivityAction>> Request Target Recon <<OperationalActivityAction>> Analyse Target Data <<OperationalActivityAction>> Request Bombardment <<Node>> Spot Team : OperationalNode Target Location <<OperationalActivityAction>> Recon Target Recon Report Fire Order <<Node>> Artillery : OperationalNode <<OperationalActivityAction>> Bombard Target Figure 6-20: UML Activity Diagram Swim-Lanes <<OperationalActivity>> Analyse Target Data Recon Report <<OperationalActivityAction>> Enhance Images Processed Images <<OperationalActivityAction>> Analyse Images Strike Recommendation <<OperationalActivityAction>> Make Strike Decision Figure 6-21: UML Activity Diagram (showing actions) MODAF-M7-022 Version

83 6.5.3 OV-5 MODAF Meta Model Support Dependency (from UML::Classes::Dependencies) ActivityConductedAtNode (from MODAF::Operational) -nodeusagecontext:property + conductedat {redefines client} CallBehaviorAction (from UML::Actions::BasicActions) Activity (from UML::Activities::BasicActivities) Node OperationalActivityAction (from MODAF::Operational) + equivalentactivity { redefines behaviour} OperationalActivity (from MODAF::Operational) + activityconducted {redefines supplier} OutputPin (from UML::Actions::BasicActions) InputPin (from UML::Actions::BasicActions) Class (from UML::CompositeStructures::StructuredClasses) OpActivityMechanismPin (from MODAF::Operational) OpActivityOutputPin (from MODAF::Operational) + outputpins {redefines /output} + inputpins { redefines /input} OpActivityInputPin (from MODAF::Operational) OpActivityControlPin (from MODAF::Operational) + fromfrom {redefines source } ObjectFlow (from UML::Activities::BasicActivities) + flowto {redefines target} OperationalActivityFlow (from MODAF::Operational) * + realisingflows { redefines realizingactivityedge} + flow {redefines client} InfoElementInFlow (from MODAF::Operational) InformationItem (from UML::AuxiliaryConstructs::InformationFlows) InformationFlow (from UML::AuxiliaryConstructs::InformationFlows) InformationElement + element {redefines supplier} + conveyedelement { redefines conveyed} Usage (from UML::Classes::Dependencies) InformationExchange (from MODAF::Operational) -requirementtext:string Figure 6-22: MODAF Meta Model Excerpt for OV-5 MODAF-M7-022 Version

84 226. The M 3 aims to cover the basic process modelling techniques used by military modellers. The most widely used is IDEF0, though there are many other notations in use which have a similar level of functionality. Obviously, as the M 3 defines an abstract syntax for a UML profile, the basis for the model is the UML activity model. However, the UML activity model makes a distinction (which is unnecessary for MODAF purposes) between activity and action. In order to reconcile this with other modelling techniques (such as IDEF0) which allow sub-activities to be defined beneath and activity, it is necessary to constrain how the UML activity model is used for MODAF The main constraint is that an <<OperationalActivity>> (stereotype of Activity) and an <<OperationalActivityAction>> (stereotype of CallBehaviourAction) must be created for every activity that is modelled. This allows the sub-activities to be modelled in a similar way to IDEF0 without breaking the way UML is used. In reality, any serious activity modeller would need to create an activity and an action anyway because UML only allows properties to be defined against activities, but only allows flows between actions Should a future version of the UML meta model rationalise the behavioural models, it may be possible to simplify this approach in a future release of MODAF The model elements used in OV-5 are: a. ActivityConductedAtNode - Asserts that an <<OperationalActivity>> is conducted at a <<Node>>. Should the same type of node be used in different contexts in the architecture, and the activity is conducted under only one of the contexts, that context is provided by the nodeusagecontext property. b. InfoElementInFlow - Asserts that an information element is passed along the flow between activities c. InformationElement - a formalized representation of information subject to an operational process d. InformationExchange - A specification of the information that is to be exchanged. e. Node - A logical entity which creates, consumes or manipulates information. A <<Node>> is a usually grouping of organizations and systems (and other nodes) for a particular purpose. f. OpActivityControlPin - A port for things flowing into an activity which constrain or govern how the activity is performed g. OpActivityInputPin - A port for flows that feed into an activity h. OpActivityMechanismPin - A port for things flowing into an activity which support or perform the activity i. OpActivityOutputPin - A port for flows that leave an activity j. OperationalActivity - A process carried out by a person or organisation - i.e. not an automated function. k. OperationalActivityAction - Used to relate an OperationalActivity to its sub-activities. Also provides a means for attaching information (properties) to an activity. Note that an OperrationalActivityAction will be created for every OperationalActivity to provide a way to manage sub-activities, and to allow flows between activities. l. OperationalActivityFlow - A flow of information from one activity to another. MODAF-M7-022 Version

85 6.6 Operational Activity Sequence & Timing Description (OV-6a, 6b & 6c) Overview of Operational Activity Sequence and Timing Descriptions (OV-6a, 6b, & 6c) 230. OV Products discussed in previous sections model the static structure of the Architecture elements and their relationships. Many of the critical characteristics of an Architecture are only discovered when the dynamic behaviour of these elements is modelled to incorporate sequencing and timing aspects of the Architecture The dynamic behaviour referred to here concerns the timing and sequencing of events that capture operational behaviour of a business process or mission thread for example. Thus, this behaviour is related to the activities of OV-5. Behaviour modelling and documentation is essential to a successful Architecture description, because it is how the Architecture behaves that is crucial in many situations. Knowledge of the Operational Nodes, activities, and information exchanges is crucial; but knowing when, for example, a response should be expected after sending message X to Node Y can also be crucial to achieving successful operations Several modelling techniques may be used to refine and extend the Architecture s OV to adequately describe the dynamic behaviour and timing performance characteristics of an Architecture, such as logical languages such as LDL [Naqvi, 1989] Harel Statecharts [Harel, 1987a, b], petri- nets [Kristensen, 1998], IDEF3 diagrams [IDEF3, 1995], and UML statechart and sequence diagrams [OMG, 2001]. OV-6 includes three such models. They are: a. Operational Rules Model (OV-6a) b. Operational State Transition Description (OV-6b) c. Operational Event-Trace Description (OV-6c) 233. OV-6 Products portray some of the same Architecture data elements, but each also portrays some unique Architecture data elements. OV-6b and OV-6c may be used separately or together, as necessary, to describe critical timing and sequencing behaviour in the OV. Both types of Products are used by a wide variety of different business process methodologies as well as Object-Oriented methodologies. OV-6b and OV-6c describe Operational Activity or business process responses to sequences of events. Events may also be referred to as inputs, transactions, or triggers. Events can be internally or externally generated and can include such things as the receipt of a message, a timer going off, or conditional tests being satisfied. When an event occurs, the action to be taken may be subject to a rule or set of rules (conditions) as described in OV-6a OV-6a Product Description Product Definition 234. The Operational Rules Model specifies operational or business rules that are constraints on an enterprise, a mission, operation, business, or on an Architecture. While other OV Products (e.g. OV-1, OV-2, OV-5) describe the structure and operation of a business, for the most part they do not describe the constraints and rules under which it operates MODAF-M7-022 Version

86 235. At the mission level, OV-6a may consist of doctrine, guidance, rules of engagement, and so forth. At the operation level, rules may include such things as a military Operational Plan (OPLAN). At lower levels, OV-6a describes the rules under which the Architecture or its Nodes behave under specified conditions. Such rules can be expressed in a textual form, for example, If (these conditions) exist, and (this event) occurs, then (perform these actions) Product Purpose 236. At a top level, rules will at least embody the concepts of operations defined in OV-1a and will provide guidelines for the development and definition of more detailed rules and behavioural definitions that will occur later in the Architecture definition process Detailed Product Description 237. Operational Rules are statements that constrain some aspect of the mission or the Architecture. Rules are expressed in natural language (English) in one of two forms: a. Imperative a statement of what shall be under all conditions e.g. Battle Damage Assessment (BDA) shall only be carried out under fair weather conditions b. Conditional Imperative a statement of what shall be, in the event of another condition being met If battle damage assessment shows incomplete strike, then a re-strike shall be carried out As the View name implies, the rules captured in OV-6a are operational (i.e., missionoriented) whereas systems-oriented rules are defined in SV-10. OV-6a rules can include such guidance as the conditions under which operational control passes from one entity to another, or the conditions under which a human role is authorised to proceed with a specific activity A rule defined in OV-6a may be applied to any Architectural Element defined in an OV. Often, OV-6a rules are associated with activities in OV-5. For example, a rule might prescribe the specific set of inputs required to produce a given output. OV-6a can also be used to extend the capture of business requirements by constraining the structure and validity of OV-7 elements. Rules defined in an OV-6a may optionally be presented in any other OV for example, a rule battle damage assessment shall be carried out under fair weather conditions may be shown linked to the Conduct BDA activity in OV-5. Any natural language rule presented in an Operational Viewpoint Product shall also be listed in OV-6a Detailed rules can become quite complex, and the structuring of the rules themselves can often be challenging. MODAF does not specify how OV-6a rules will be specified, other than in English. Rule ID Applies to Rule Specification R1 All All communications shall be encrypted to TS level according to CESG guidelines R2 Conduct BDA (Operational Activity) Battle damage assessment shall be carried out under fair weather conditions. R3 Make Re-Strike If battle damage assessment shows incomplete Decision strike, then a re-strike shall be carried out. (Operational Activity) Figure 6-23: Example Operational Rules (OV-6a) MODAF-M7-022 Version

87 6.6.3 OV-6a UML Representation 241. There is no specific UML diagram that is applicable to the OV-6a View. However, UML constraints are a direct analogue and have been stereotyped to <<OperationalConstraint>> in the M 3 and these may be applied to other Products e.g. activities in OV-5: <<OperationalActivityAction>> Conduct Battle Damage Assessment {Battle damage assessment shall be carried out under fair weather conditions} Battle Damage Assessment <<OperationalActivityAction>> Make Re-Strike Decision {If battle damage assessment shows incomplete strike, then a re-strike shall be carried out} Figure 6-24 Example of OV-6a rules shown on an OV-5 UML Product OV-6a MODAF Meta Model Support Constraint (from UML::Classes::Kernel) OperationalConstraint (from MODAF::Operational) Figure 6-25: MODAF Meta Model Excerpt for OV-6a 242. An operational constraint may be applied to anything to which a UML 2.0 constraint may be applied - i.e. UML:Element. This means that an operational constraint may be applied to virtually every element defined by the M The model elements used in OV-6a are: a. OperationalConstraint - A rule governing an operational behaviour or property OV-6b Product Description Product Definition 244. The Operational State Transition Description is a graphical method of describing how an Operational Node or activity responds to various events by changing its state. The diagram represents the sets of events to which the Architecture will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action. MODAF-M7-022 Version

88 Product Purpose 245. The explicit sequencing of activities in response to external and internal events is not fully expressed in OV-5. An Operational State Transition Description can be used to describe the explicit sequencing of the operational activities. Alternatively, OV-6b can be used to reflect the explicit sequencing of actions internal to a single Operational Activity or the sequencing of operational activities with respect to a specific operational node Detailed Product Description 246. OV-6b is based on the statechart diagram. A state machine is defined as a specification that describes all possible behaviours of some dynamic model element. Behaviour is modelled as a traversal of a graph of state Nodes interconnected by one or more joined transition arcs that are triggered by the dispatching of a series of event instances. During this traversal, the state machine executes a series of actions associated with various elements of the state machine. [OMG, 2003] 247. State chart diagrams can be unambiguously converted to structured textual rules that specify timing aspects of operational events and the responses to these events, with no loss of meaning. However, the graphical form of the state diagrams can often allow quick analysis of the completeness of the rule set, and detection of dead ends or missing conditions. These errors, if not detected early during the operational analysis phase, can often lead to serious behavioural errors in fielded systems or to expensive correction efforts Figure 6-26 provides a template for a simple OV-6b. The black dot and incoming arrow point to initial states (usually one per diagram), while terminal states are identified by an outgoing arrow pointing to a black dot with a circle around it. States are indicated by rounded corner box icons and labelled by name or number and, optionally, any actions associated with that state. Transitions between states are indicated by one-way arrows labelled with an event/action notation that indicates an event-action pair, and which semantically translates to: when an event occurs, the corresponding action is executed. This notation indicates the event that causes the transition and the ensuing action (if any) associated with the transition. Figure 6-26: Operational State Transition Description High-Level Template OV-6b UML Representation 249. OV-6b may be produced in UML using statechart diagrams that contain simple states and composite states. They also contain transitions, which are described in terms of triggers or events (generated as a result of an action). MODAF-M7-022 Version

89 Ops Control Attack Target Request Received Requesting TargetInformation Weather Clear Awaiting Suitable Weather Conditions Strike Unsuccessful Spot Team Intel Received BLOS Imagery Unavailable Processing Spot Team Intel Intel Inconclusive Requesting BLOS Imagery Target Confirmed BLOS Imagery Available Planning Strike BLOS Imagery Confirms Target Processing BLOS Imagery BLOS Imagery Inconclusive Strike planned Executing Strike Strike Successful BLOS Imagery Confirms No Target Intel confirms no target Figure 6-27 UML diagram for Operational State Transition Description OV-6b OV-6b MODAF Meta Model Support BehaviorStateMachines (from UML::StateMachines) StateMachine OperationalStateDescription (from MODAF::Operational) -nodeusagecontext:nodeassemblyusage[0..1] {redefines context} OperationalStateDescriptionOwner (from MODAF::Operational) Activity (from UML::Activities::BasicActivities) OperationalActivity (from MODAF::Operational) -nodeusagecontext:property Node Class (from UML::CompositeStructures::StructuredClasses) Figure 6-28: MODAF Meta Model Excerpt for OV-6b MODAF-M7-022 Version

90 250. For OV-6b and SV-10b, the complete use of stereotyping has not been deemed necessary - UML state machines are ideal for representing these products. However, to constrain the use and enable a distinction between OV-6b and SV-10b state models, the UML:StateMachines:BehaviorStateMachines:StateMachine metaclass is stereotyped to <<OperationalStateDescription>> for OV-6b and <<SystemStateMachine>> for SV-10b 251. The model elements used in OV-6b are: a. Node - A logical entity which creates, consumes or manipulates information. A <<Node>> is a usually grouping of organizations and systems (and other nodes) for a particular purpose. b. OperationalActivity - A process carried out by a person or organisation - i.e. not an automated function. May be related to the node where the process is carried out via the context relationship. Should the same type of node be used in different contexts in the architecture, the context is provided by the nodeusagecontext property. c. OperationalStateDescription - A rule governing an operational behaviour or property. d. OperationalStateDescriptionOwner - An item whose behaviour may be represented by a OperationalStateDescription OV-6c Product Description Product Definition 252. The Operational Event-Trace Description provides a time-ordered examination of the information exchanges between participating Operational Nodes as a result of a particular scenario. Each event-trace diagram will have an accompanying description that defines the particular scenario or situation Product Purpose 253. OV-6c is valuable for moving to the next level of detail from the initial operational concepts. An OV-6c Product helps define Node interactions and operational threads An OV-6c Product can also help ensure that each participating Operational Node has the necessary information it needs at the right time in order to perform its assigned Operational Activity Detailed Product Description 255. OV-6c allows the tracing of actions in a scenario or critical sequence of events. OV-6c can be used by itself or in conjunction with OV-6b to describe the dynamic behaviour of business processes or a mission/operational thread. An operational thread is defined as a set of operational activities, with sequence and timing attributes of the activities, and includes the information needed to accomplish the activities. A particular operational thread may be used to depict a military capability. In this manner, a capability is defined in terms of the attributes required to accomplish a given mission objective by modelling the set of activities and their attributes. The sequence of activities forms the basis for defining and understanding the many factors that impact on the overall military capability The Framework does not endorse a specific event-trace modelling methodology, however, UML sequence diagrams [OMG, 2003] seem the most appropriate for this purpose. If UML is not used, an OV-6c Product may be developed using any modelling notation that supports the layout of timing and sequence of activities along with the information exchanges that occur between Operational Nodes for a given scenario. Different scenarios will be depicted by separate diagrams. Figure 6-29 shows an example OV-6c Product using a UML Sequence Diagram. The items across the top of the diagram are Operational Nodes, usually MODAF-M7-022 Version

91 organisations, organisations types, or human roles, which take action based on certain types of events. Each Operational Node has a lifeline associated with it that runs vertically. Specific points in time can be labelled on the lifelines, running down the left-hand side of the diagram. One-way arrows between the Node lifelines represent events, and the points at which they intersect the lifelines represent the times at which the Nodes become aware of the events. Events represent information passed from one lifeline to another and actions associated with the event. Labels indicating timing constraints or providing descriptions can be shown in the margin or near the event arrow that they label. The direction of the events represents the flow of control from one Node to another. <<NodeAssemblyUsage>> <<NodeAssemblyUsage>> <<NodeAssemblyUsage>> <<NodeAssemblyUsage>> <<NodeAssemblyUsage>> <<NodeAssemblyUsage>> <<NodeAssemblyUsage>> <<NodeAssemblyUsage>> PJHQ: OperationalNode BDE HQ: OperationalNode AircraftCarrier: OperationalNode Nemesis: OperationalNode FightingPatrol: OperationalNode GroundStation: OperationalNode Kestrel: OperationalNode SPECS2: OperationalNode Tasking Order Tasking Order Tasking Order Tasking Order Tasking Order Tasking Order Tasking Order ISTAR Info ISTAR Info ISTAR Info ISTAR Info ISTAR Info Task complete Figure 6-29: Operational Event-Trace Description (OV-6c) UML-type OV-6c UML Representation 257. UML sequence diagrams may be used to model OV-6c as shown in Figure MODAF-M7-022 Version

92 OV-6c MODAF Meta Model Support BasicInteractions (from UML::Interactions) Interaction OperationalInteractionSpecification (from MODAF::Operational) {redefines interaction} Lifeline { redefines lifeline} OperationalNodeLifeline (from MODAF::Operational) { redefines represents} Property (from UML::CompositeStructures::InternalStructures) NodeAssemblyUsage Figure 6-30: MODAF Meta Model Excerpt for OV-6c 258. For OV-6c and SV-10c, the complete use of stereotyping has not been deemed necessary - UML sequence (interaction) diagrams are ideal for representing these products. However, to constrain the use, and enable a distinction between OV-6c and SV-10c interaction models, the Interaction and Lifeline metaclasses are stereotyped The model elements used in OV-6c are: a. NodeAssemblyUsage - Used to link a parent node to its sub-nodes. Only NodeAssemblyUsage may be used to represent a node-subnode relationship. b. OperationalInteractionSpecification - A specification of the interactions between nodes in an operational architecture. c. OperationalNodeLifeline - A lifeline which represents a usage of a node in an operational architecture MODAF-M7-022 Version

93 6.7 Logical Data Model (OV-7) OV-7 Product Description Product Definition 260. The Logical Data Model describes the structure of an Architecture domain s system data types and the structural business process rules (defined in the Architecture s Operational Viewpoint) that govern the system data. It provides a definition of Architecture domain data types, their attributes or characteristics, and their interrelationships Product Purpose 261. An OV-7 Product showing the domain s system data types or Entity definitions, is a key element in supporting interoperability between Architectures, since these definitions may be used by other organisations to determine system data compatibility. Often, different organisations may use the same Entity name to mean very different kinds of system data with different internal structure. This situation will pose significant interoperability risks, as the system data models may appear to be compatible, each having a Target Track data Entity but having different and incompatible interpretations of what Target Track means An OV-7 may be necessary for interoperability when shared system data syntax and semantics form the basis for greater degrees of information systems interoperability, or when a shared database is the basis for integration and interoperability among business processes and, at a lower level, among systems Detailed Product Description 263. OV-7 defines the Architecture domain s system data types (or entities) and the relationships among the system data types. For example, if the domain is missile defence, some possible system data types may be trajectory and target with a relationship that associates a target with a certain trajectory. On the other hand, Architecture data types for the MODAF (i.e., MODAF-defined Architecture data elements, AV-2 data types, and ERM entities) are things like an Operational Node or Operational Activity. OV-7 defines each kind of system data type associated with the Architecture domain, mission, or business as its own Entity, with its associated attributes and relationships. These Entity definitions correlate to OV-3 information elements and OV-5 inputs, outputs, and controls OV-7 is not be confused with the M 3. OV-7 is an Architectural Product and describes information about a specific Architecture domain. The M 3 is not an Architectural Product. The M 3 is a specification of the underlying semantics for MODAF Products. M 3 acts as a specification for XMI data exchange between MODAF tools and as a guide for MODAF repository implementation The purpose of a given Architecture helps to determine the level of detail needed in this Product. A formal Data Model that is detailed down to the level of Architecture domain system data, their attributes, and their relationships is required for some purposes, such as when validation of completeness and consistency is required for shared data resources. However, for other purposes, a higher- level conceptual Data Model of the domain of interest will suffice, such as a subject area model or an Entity-relation model without attributes. The term logical Data Model is used here in this context, regardless of the level of detail the model exhibits The Architecture data elements for OV-7 include descriptions of entity, attribute, and relationship types. Attributes can be associated with entities and with relationships, depending on the purposes of the Architecture. MODAF-M7-022 Version

94 267. Figure 6-31 provides a template for OV-7 (with attributes). The format is intentionally generic to avoid implying a specific methodology. Figure 6-31: Logical Data Model (OV-7) Template OV-7 UML Representation 268. OV-7 may be modelled in UML using a class diagram with appropriate M 3 defined stereotypes as shown in Figure To maintain compatibility with more mainstream data modelling approaches (e.g. E-R modelling), only UML classes, associations and properties are allowed in OV-7. << DataModel >> StoresRequest << entity >> SuppliesRequest -quantity:integer + requestsubmittedto << entity >> Store -name:string -location:string + stock * << entity >> StockHolding -quantity:integer << entity >> AmmunitionRequest + typeofammunition << entity >> SupplyType -name:string -description:string -natostocknumber:string + stocktype Figure 6-32: UML Class Diagram for Logical Data Model (OV-7) Template MODAF-M7-022 Version

95 6.7.3 OV-7 MODAF Meta Model Support InformationItem (from UML::AuxiliaryConstructs::InformationFlows) Realization (from UML::Classes::Dependencies) InformationElement + definedelement { redefines client} DefinitionOfInfoElement + definition {redefines supplier} InformationDescriptor LogicalDataModel (from MODAF::Operational) DataModel Package (from UML::Classes::Kernel) Generalization (from UML::Classes::Kernel) + entities * {redefines ownedmember} SubtypeRelationship + subtype {redefines specific} + supertype Entity Class (from UML::Classes::Kernel) {redefines general} { subsets ownedattribute} EntityRelationship {subsets ownedend} {subsets memberend} Attribute Property (from UML::Classes::Kernel) 2 Association (from UML::Classes::Kernel) Figure 6-33: MODAF Meta Model Extract for OV Data models in MODAF have classes, relationships and attributes, effectively giving Entity-Relationship capability. Subtyping (generalisation / specialisation) is also permitted. Although not shown in an OV-7 (or in an OV-5 or OV-2), there is often a need define the data MODAF-M7-022 Version

96 structure of an <<InformationElement>> - this is achieved by using a <<DefinitionOfInfoElement>> stereotype The model elements used in OV-7 are: a. Attribute - A property of an entity. b. DataModel - A structural specification of data, showing classifications of data elements and relationships between them. c. DefinitionOfInfoElement - Relates an <<InformationElement>> to the information descriptor (i.e. a data model definition or aspect) which defines it. d. Entity - A definition (type) of an item of interest. e. EntityRelationship - Asserts that there is a relationship between two entities. f. InformationDescriptor - A data model element that can be used to define an item of information (InformationElement) g. InformationElement - a formalized representation of information subject to an operational process h. LogicalDataModel - A <<LogicalDataModel>> is a specification of business information requirements as a formal data structure, where relationships and classes (entities) are used to specify the logic which underpins the information. i. SubtypeRelationship - Asserts that one entity (subtype) is a specialization of the other (supertype). MODAF-M7-022 Version

97 7 System View Products 271. SVs are common to MODAF and DoDAF; SV-1 and 2 however, have been customised to provide for MOD requirements. SVs Products provide a set of graphical and textual Products that describe systems and interconnections. There are fifteen SV Products: a. Systems Interface Description (SV-1) b. Systems Communications Description (SV-2a,2b,2c) c. Systems-Systems Matrix (SV-3) d. Systems Functionality Description (SV-4) e. Operational Activity to Systems Functionality Traceability Matrix (SV-5) f. Systems Data Exchange Matrix (SV-6) g. Systems Performance Parameters Matrix (SV-7) h. Systems Evolution Description (SV-8) i. Systems Technology Forecasts (SV-9) j. Systems Functionality and Timing Descriptions (SV-10a, 10b, and 10c) k. Physical Schema (SV-11) 272. A description for each of these Views is included below. MODAF-M7-022 Version

98 7.1 Systems Interface Description (SV-1) SV-1 Product Description Product Definition 273. The Systems Interface Description depicts systems and identifies the interfaces between them. An SV-1 also shows the Nodes at which those systems are located Product Purpose 274. SV-1 identifies where relationships exist between systems i.e. the key interfaces. Sub-system assemblies may be identified in SV-1 to any level (i.e. depth) of decomposition the architect sees fit. SV-1 may also identify the System Nodes (e.g. Platforms) at which systems are deployed, and optionally overlay Operational Nodes that utilise those systems. In many cases, an operational node depicted in an OV-2 product may well be the same as the System Node that is shown in SV Detailed Product Description 275. SV-1 links together the OV and SV by depicting which systems are resident at which Nodes. Systems Nodes may in reality be Operational Nodes, and such duality is permissible indeed M 3 provides only for the concept of <<Node>> deliberately to allow this duality. The aim of the SV-1 View is to record the system characteristics of the Node and how the Needlines from OVs are realised as system interfaces. Therefore SV-1 also shows the key interfaces between systems, and may indicate which Needlines (specified in OV-2) are satisfied by each of the interfaces. OV-2 depicts the Operational Nodes representing organisations, organisation types, and/or human roles, and the required communications (Needlines) between those Nodes. SV-1 depicts how those Operational Nodes are deployed at systems Nodes, which systems make up the systems Nodes and the interfaces which implement the Needlines specified in OV The term System in the framework is used to denote a Family of Systems (FoS), System of Systems (SoS), nomenclatured system, or a subsystem. An item denotes a hardware or software item. The term System Node describes a logical or physical deployment for Operational Nodes e.g. locations, Platforms, units, facilities, etc. The following are documented in an SV-1: a. Systems and the interfaces between them b. System Nodes and the Operational Nodes deployed at them c. Hardware/software items and their associated standards 277. Details of the communications infrastructure (e.g., physical links, communications networks, routers, switches, communications systems, satellites) are documented in the Systems Communication Description (SV-2) In addition to depicting System Nodes and systems, SV-1 addresses system interfaces. An interface, as depicted in SV-1, is a simplified, abstract representation of one or more communications paths between systems Nodes or between systems (including communications systems) and is usually depicted graphically as a straight line. SV-1 depicts all interfaces that are of interest for the Architecture purpose An SV-1 interface is the systems representation of an OV-2 Needline. A single Needline shown in the OV may translate into multiple system interfaces. The actual implementation of an interface may take more than one form (e.g., multiple physical links). MODAF-M7-022 Version

99 Details of the physical links and communications networks that implement the interfaces are documented in SV-2. Characteristics of the interface are described in Systems-Systems Matrix (SV-3). System functions and system data flows are documented in a Systems Functionality Description (SV-4), and the system data carried by an interface are documented in the Systems Data Exchange Matrix (SV-6) A systems interface may be classified as a Key Interface (KI), as defined in the MODAF Taxonomy. A KI is defined as an interface where one or more of the following criteria are met: a. The interface spans organisational boundaries (may be across instances of the same system, but utilised by different organisations); b. The interface is mission critical; c. The interface is difficult or complex to manage; or d. There are capability, interoperability, or efficiency issues associated with the interface If desired, annotations summarising the system data exchanges carried by an interface may be added to SV Wherever possible, an SV-1 will show Operational Nodes, System Nodes and system interfaces for the entire Architecture on the same diagram. It will also identify which OV-2 Needlines are implemented by each system interface. Figure 7-1 and Figure 7-2 show typical SV-1 diagrams. Figure 7-1 is a generic example showing systems deployed at systems Nodes, being used by Operational Nodes, as well as unmanned systems (e.g. satellites, autonomous vehicles, etc.).figure 7-2 is an example from the US Navy, showing Operational Nodes (SACC, JIC, etc.) located at Platforms, and the supporting systems Nodes. Figure 7-1: Generic SV-1 Diagram Example MODAF-M7-022 Version

100 Figure 7-2: SV-1 Example from US Navy using Swim Lanes MODAF-M7-022 Version

101 7.1.2 SV-1 UML Representation 283. SV-1 may be expressed as a UML class diagram, using the stereotypes defined in the M 3. Figure 7-3 shows an example SV-1 diagram in UML, based on the generic example in Figure 7-1. The type of link between the systems is governed by the Taxonomy, and is shown on the diagram as a comment. <<DiagramCompositeClass>> MySystemDiagram <<Node>> :Land Component Command <<Node>> :UAV Control <<System>> :ISTAR Analysis Suite <<System>> :Image Processing System <<System>> :UAV <<System>> :IR Camera <<System>> :Viewing System <<System>> :Stills Camera <<System>> :Video Camera <<System>> :Online Video Library <<Node>> :Spot Team <<System>> :Ruggedised Video Camera <<System>> :Video Comms Module Figure 7-3: Example UML for SV-1 MODAF-M7-022 Version

102 7.1.3 SV-1 MODAF Meta Model Support UnitOfMeasure DataType (from UML::Classes::Kernel) ValueSpecification (from UML::Classes::Kernel) Node + parent {redefines class } + child {redefines type} NodeAssemblyUsage {redefines datatype} + uom PhysicalProperty -maxvalue:literalspecification[0..1] + defaultvalue 0..1 {subsets ownedelement} owningproperty Property {subsets owner} (from UML::Classes::Kernel) + owningnode {redefines class} ResourceForNode -resourceisnode:boolean + assigneditem {redefines class} PropertyAssignedItem Property (from UML::CompositeStructures::InternalStructures) ConnectorEnd (from UML::CompositeStructures::InternalStructures) + deployedresource {redefines type} Resource System (from MODAF::Systems) + parent {redefines class} + child SystemAssemblyUsage (from MODAF::Systems) {aggregation = composite} NestedConnectorEnd -propertypath:property[2..*ordered] {redefines type} + connectioncontext {redefines role} Class (from UML::CompositeStructures::StructuredClasses) SystemConnectorEnd (from MODAF::Systems) 2 {subsets end} DiagramCompositeClass + fromsystem {subsets memberend[1]} + tosystem {subsets memberend[2]} SystemConnectionSpecification (from MODAF::Systems) AssociationClass (from UML::Classes::AssociationClasses) {subsets type} Connector (from UML::CompositeStructures::InternalStructures) SystemConnector (from MODAF::Systems) Figure 7-4: MODAF Meta Model Extract for SV An SV-1 product can show systems deployed at nodes, connections between nodes, and connections between systems. The mechanism used is a UML composite class model. Nodes are decomposed using the <<NodeAssemblyUsage>> stereotype, and systems are overlaid on nodes using the <<ResourceForNode>> stereotype. Systems are decomposed using the <<SystemAssemblyUsage>> stereotype 285. Connections between systems are defined using Association Classes stereotyped as <<SystemConnectionSpecification>>. The connections are realised as Connectors, stereotypes as <<SystemConnector>> Although system properties tend not to be shown on SV-1 diagrams, modelling tools often prompt the user for property information whilst developing the SV-1 product. This is modelled using the <<PhysicalProperty>> stereotype As with OV-2, it may be necessary to employ a <<DiagramCompositeClass>> to act as the top level class in the composite class model when connections are required between elements that would otherwise have been at the top level of the model. MODAF-M7-022 Version

103 288. The model elements used in SV-1 are: a. DiagramCompositeClass - DiagramCompositeClass is used as a top-level class for a composite class diagram when it is not possible to use an architectural element as the toplevel class. This usually arises when connections are required between two classes which are at the top level - which is not generally possible. In such a case, the two top-level architectural elements would be properties of the DiagramCompositeClass, enabling connections to be made between the properties. b. NestedConnectorEnd - To maintain compatibility with the SysML standard ( MODAF has tried to re-use as many of the SysML stereotypes as possible. c. Node - A logical entity which creates, consumes or manipulates information. A <<Node>> is a usually grouping of organizations and systems (and other nodes) for a particular purpose. d. NodeAssemblyUsage - Used to link a parent node to its sub-nodes. Only NodeAssemblyUsage may be used to represent a node-subnode relationship. e. PhysicalProperty - A property of something in the physical world, expressed in amounts of a unit of measure. The property may have a required value - either specified by the defaultvalue from uml::property attribute, or the minvalue and maxvalue to specify a required range. f. PropertyAssignedItem - The abstract superclass of all classes which may have physical properties g. Resource - Something that is able to supply functionality, information or material. h. ResourceForNode - An assertion that a resource is provided to a node. If resourceisnode is true then the resource itself is the node - e.g. an "Aircraft Carrier" <<System>> could be the "Maritime Ops Control" <<Node>>, or a "Spot Team" <<Organisation>> could be the "Forward Observation" <<Node>> i. System - A coherent combination of physical artefacts, energy and information, assembled for a purpose. j. SystemAssemblyUsage - Used to link a parent system to its sub-systems. Only <<SystemAssemblyUsage>> may be used to represent a system-subsystem relationship. k. SystemConnectionSpecification - Asserts that a relationship is possible between two types of systems. <<SystemConnectionSpecification>> AssociationClass so that properties may be assigned to the connection (<<SystemConnector>>) that instantiates the relationship. l. SystemConnector - Asserts that a connection exists between two parts in a system composite structure model. m. SystemConnectorEnd - The end of a connector between systems - note that when port-to-port connections are to be specified, <<SystemPortConnectorEnd>> should be used. n. UnitOfMeasure - A determinate amount or quantity adopted as a standard of measurement for other amounts or quantities of the same kind MODAF-M7-022 Version

104 7.2 Systems Communications Description (SV-2a, 2b, 2c) Overview of System Communications Description (SV-2a, 2b, & 2c) 289. The SV-2 View is split into three Views which define the communications links between systems. The Views are: a. SV-2a System Port Specification - defines the ports on each system, and the protocol / hardware stack that is specified or implemented for each of those ports. b. SV-2b System to System Port Connectivity - defines the connections between individual ports and shows the protocols and hardware spec used for each connection. c. SV-2c System Connectivity Clusters - defines the bundles of system to system connections that go to make up an inter-nodal connection (see SV-1) The goal of these Views is to provide a comprehensive specification of how systems are connected, what interfaces each system exposes (ports), the hardware interface used, and the protocols which are transmitted across the interface. Key elements are repeated from View to View, and are also common to the SV-1 View. These key elements are: a. Systems b. Nodes c. Ports d. System-to-system connections e. Inter-nodal connections 291. The elements are shown in different perspectives in the different Views. In an SV-1 View, the systems are logically grouped by the Nodes they belong to (or are located at). The SV-1 View also shows the connections between Nodes, and between systems. In the SV-2 Views, more information is added particularly about the ports on each system and the protocols which each port supports. In addition, the SV-2 Views describe which protocols are supported for specific system-to-system connections The SV-2 Views are key to implementing the MOD s Network Enabled Capability strategy. They enable acquisition specialists and systems engineers to quickly plan and visualise how communications between systems are to be implemented. When MODAF is used as an analytical tool for existing systems, the SV-2 Views provide a detailed way to document the interfaces exposed by those systems SV-2a Product Description Product Definition 293. A System Port Specification (SV-2a) Product specifies the ports on a system, and the protocols used by those ports when communicating with other systems Product Purpose 294. An SV-2a Product is intended to provide a specification for how each system in the Architecture can communicate with other systems. MODAF-M7-022 Version

105 Detailed Product Description 295. An SV-2a View is used to fully describe the communications protocols and hardware specifications of each port on a system. The View comprises of one diagram for each system in the Architecture. Each port on the system is specified in terms of: a. its name, b. the communications protocols used (e.g. OSI Stack), and c. the physical port specification (e.g. the physical element of the stack) In many cases, a physical port may support more than one protocol in parallel (e.g. a TCP/IP network supporting http, ftp, telnet, etc.). All supported protocols relevant to the Architecture shall be shown in the SV-2a View. The protocols will also be listed in TV-1 and the same class in the M 3 will support SV-2a and TV-1 Figure 7-5 shows an example port specification port 3b and 3c use the same physical port to support POP3 and SMTP for e- mail over TCP/IP. System 3 Port: 3a PLCS DEX 7 HTTP TCP/IP Bowman Port: 3b POP3 TCP/IP Ethernet RJ-45 Socket Port: 3c SMTP TCP/IP Ethernet RJ-45 Socket Figure 7-5: Example System Port Specification 297. If a port supports a particular data protocol, supported by an information model, this will also be specified. In Figure 7-5, Port 3a supports the PLCS DEX 7 XML 11 Schema definition for in-service feedback Any protocol referred to in an SV-2a diagram must be defined in the TV-1 Technical Standards View 11 Extensible Mark-up Language, XML. MODAF-M7-022 Version

106 7.2.3 SV-2a UML Representation <<ProtocolStack>> Plain Text App HTTP TCP/IP ETHERNET LOS COMMS <<System>> Info Management <<SystemPort>> P1 <<ProtocolStack>> File Transfer FTP TCP/IP ETHERNET LOS COMMS <<SystemPort>> P2 <<ProtocolStack>> Query Service CORBA RPC TCP/IP Link 77 <<SystemPort>> P3 Figure 7-6: UML diagram for SV-2a 299. It is noted that the emerging standard extension of UML, the System Engineering Modelling Language, (SysML) may also offer a solution for SV-2a protocol stacks SV-2a MODAF Meta Model Support Class (from UML::CompositeStructures::StructuredClasses) Resource Constraint (from UML::Classes::Kernel) Port (from UML::CompositeStructures::Ports) Standard -identifier:string -ratificationdate:timeexpression -withdrawaldate:timeexpression -publishedwebsite:string -publisher:string -name:string -version:string System (from MODAF::Systems) system {redefines class } * SystemPort (from MODAF::Systems) PortType (from MODAF::Systems) {subsets type} ProtocolSpecifiedItem (from MODAF::Systems) * + specifiedon {redefines constraineditem} ProtocolStack (from MODAF::Systems) -protocolrefs:constraint[1..*ordered] MODAF-M7-022 Version

107 Figure 7-7: MODAF Meta Model Extract for SV-2a 300. The purpose of an SV-2a is to show the ports of a system - <<SystemPort>> - and the protocols supported by each of those ports. The protocols are specified by applying a <<ProtocolStack>> Constraint to the port, or to the <<PortType>> that defines it The model elements used in SV-2a are: a. PortType - A <<PortType>> is a type of <<System>> which is used to provide an interface to which other systems connect. A PortType may be implemented as a SystemPort. b. ProtocolSpecifiedItem - The superclass of items which may have a protocol specified. c. ProtocolStack - A protocol stack is an ordered list of protocols that are specified for a system port or system connection. The protocols are specified by the taxonomy, with the tagged-value "protocolrefs" providing the ordered references to the taxonomy. d. Resource - Something that is able to supply functionality, information or material. e. Standard - A ratified and peer-reviewed specification that is used to guide or constrain the architecture. A <<Standard>> may be applied to any element in the architecture via the constraineditem property of UML::Constraint. f. System - A coherent combination of physical artefacts, energy and information, assembled for a purpose. g. SystemPort - An interface (logical or physical) provided by a <<System>>. A <<SystemPort>> may implement a <<PortType>>, though there is no requirement for SystemPorts to be typed SV-2b Product Description Product Definition 302. A System to System Port (SV-2b) Product defines the protocol stack used by a connection between two ports. The ports may be on different systems Product Purpose 303. An SV-2b Product is used to specify the nature of a connection between two systems. This may be an existing connection, or a specification of a connection that is to be made Detailed Product Description 304. An SV-2b Product comprises a set of diagrams showing each connection between ports of systems. The architect may choose to create a diagram for each connection in the Architecture (recommended) or to show all the connections on one diagram (may be harder for readers to follow). Each diagram shall show: a. Which ports are connected; b. The systems that the ports belong to; and c. The nature of the connection in terms of the physical connectivity and any protocols that are used in the connection The SV-2b View is closely related to the SV-2a View which specifies the available protocols on each port. Any connection specified in an SV-2b View shall conform to the protocols specified on the corresponding port definitions in the SV-2a View. The examples in MODAF-M7-022 Version

108 Figure 7-8 shows how the ports defined in Figure 7-5 are connected to other ports, and the protocols used in that connection. System 3 Port: 3c SMTP TCP/IP Ethernet CAT 5 Cable 3-5 Port: 5f System 5 System 1 Port: 1a PLCS DEX 7 HTTP TCP/IP Bowman 1-3 Operational Feedback Port: 3b System 3 Figure 7-8: Example System to System Protocol Stack diagrams Any protocol referred to in an SV-2b diagram must be defined in the TV-1 Technical Standards View SV-2b UML Representation <<DiagramCompositeClass>> MySystemPortConnectivityDiagram <<ProtocolStack>> Plain Text App HTTP TCP/IP ETHERNET LOS COMMS <<System>> :InfoManagement <<SystemPort>> P1 <<SystemPort>> P5 <<System>> :InfoCollection Figure 7-9: UML diagram for SV-2c MODAF-M7-022 Version

109 7.2.7 SV-2b MODAF Meta Model Support Constraint (from UML::Classes::Kernel) Class (from UML::CompositeStructures::StructuredClasses) Standard -identifier:string -ratificationdate:timeexpression -withdrawaldate:timeexpression -publishedwebsite:string -publisher:string -name:string -version:string ProtocolStack (from MODAF::Systems) -protocolrefs:constraint[1..*ordered] Resource System (from MODAF::Systems) + system 0..1 {redefines class } Property (from UML::CompositeStructures::InternalStructures) + child { redefines type} + parent { redefines class} SystemAssemblyUsage (from MODAF::Systems) {aggregation = composite} { subsets partwithport} * + specifiedon { redefines constraineditem} * ProtocolSpecifiedItem (from MODAF::Systems) SystemPort (from MODAF::Systems) + connectionport { redefines role} SystemPortConnectorEnd (from MODAF::Systems) Port (from UML::CompositeStructures::Ports) 2 {subsets end } SystemPortConnector (from MODAF::Systems) Connector (from UML::CompositeStructures::InternalStructures) ConnectorEnd (from UML::CompositeStructures::InternalStructures) NestedConnectorEnd -propertypath:property[2..*ordered] Figure 7-10: MODAF Meta Model Extract for SV-2b 307. SV-2b shows connections (<<SystemPortConnector>>) between systems via their ports. It also shows the protocols used by the connections by applying a <<ProtocolStack>> Constraint to the connection. MODAF-M7-022 Version

110 308. System assemblies may also be shown, and this is modelled with the parent-child relationship - <<SystemAssemblyUsage>> The model elements used in SV-2b are: a. NestedConnectorEnd - To maintain compatibility with the SysML standard ( MODAF has tried to re-use as many of the SysML stereotypes as possible. b. ProtocolSpecifiedItem - The superclass of items which may have a protocol specified. c. ProtocolStack - A protocol stack is an ordered list of protocols that are specified for a system port or system connection. The protocols are specified by the taxonomy, with the tagged-value "protocolrefs" providing the ordered references to the taxonomy. d. Resource - Something that is able to supply functionality, information or material. e. Standard - A ratified and peer-reviewed specification that is used to guide or constrain the architecture. A <<Standard>> may be applied to any element in the architecture via the constraineditem property of UML::Constraint. f. System - A coherent combination of physical artefacts, energy and information, assembled for a purpose. g. SystemAssemblyUsage - Used to link a parent system to its sub-systems. Only <<SystemAssemblyUsage>> may be used to represent a system-subsystem relationship. h. SystemPort - An interface (logical or physical) provided by a <<System>>. A <<SystemPort>> may implement a <<PortType>>, though there is no requirement for SystemPorts to be typed. i. SystemPortConnector - Asserts that a connection exists between two ports belonging to parts in a system composite structure model. j. SystemPortConnectorEnd - The end of a connector between system ports SV-2c Product Description Product Definition 310. A System Connectivity Clusters (SV-2c) Product defines how individual connections between system ports are grouped into logical connections between Nodes Product Purpose 311. An SV-2c Product serves to define the connectivity requirements between Nodes, and is used for estimating requirements for physical routing and bandwidth Detailed Product Description 312. An SV-2c View provides a different viewpoint on information already specified in the OV-2, SV-1 and SV-2 Views. It is useful for estimating bandwidth requirements between Nodes. An SV-2c View is also useful when planning physical connections and routings between Nodes The SV-2c View is intended to aid analysis of the connectivity between systems and Nodes. In particular it is a useful way of highlighting redundancy issues, showing when too many or too few connections are used between Nodes i.e. there could be cost savings from using a common network, or there may be a need for redundancy to increase reliability. MODAF-M7-022 Version

111 314. An SV-2c View consists of a diagram for each inter-node connection. Each diagram shall show: a. The link between two Nodes; b. The system-to-system connections which run between those Nodes; c. Which systems are located at each node; and d. Which ports are used in the system-to-system connections Figure 7-11 shows two SV-2c diagrams, with system to system connections encapsulated in a node-link. The numbering and identification of the systems and system ports is at the discretion of the architect defining SV-2c. System 1 1a System 2 2a Node X Node-link XY 1-3 Operational Feedback 2-3 Situational Awareness 3a 3b System 3 Node Y System 3 3c Node Y Node-link YZ f System 5 Node Z Figure 7-11: Example System Connectivity Clusters View SV-2c UML Representation <<DiagramCompositeClass>> MySystemConnectivityClusterDiagram <<Node>> Land Ops Control : OperationalNode <<Node>> Forward Base : OperationalNode <<System>> :InfoManagement <<SystemPort>> P1 <<SystemPort>> P5 <<System>> :InfoCollection <<SystemPort>> P2 <<System>> :DigitalCamera <<SystemPort>> P4 Figure 7-12: SV-2c UML Representation MODAF-M7-022 Version

112 SV-2c MODAF Meta Model Support Property (from UML::CompositeStructures::InternalStructures) ConnectorEnd (from UML::CompositeStructures::InternalStructures) NestedConnectorEnd -propertypath:property[2..*ordered] ResourceForNode Port (from UML::CompositeStructures::Ports) -resourceisnode:boolean SystemPort (from MODAF::Systems) + connectionport {redefines role} SystemPortConnectorEnd (from MODAF::Systems) + owningnode {redefines class} + deployedresource {redefines type} * + system 0..1 {redefines class} 2 {subsets end} Node Resource System (from MODAF::Systems) SystemPortConnector (from MODAF::Systems) Class (from UML::CompositeStructures::StructuredClasses) DiagramCompositeClass Connector (from UML::CompositeStructures::InternalStructures) Figure 7-13: MODAF Meta Model Extract for SV-2c 316. SV-2c products are usually derivable from elements and relationships established in OV2, SV1, and SV2a & b. The information shown in an SV-2c is a summary of which nodes. The diagrams are derived by knowing which systems are deployed at given nodes (<<ResourceForNode>>) and what connections (<<SystemPortConnector>>) exist between the ports of those systems The model elements used in SV-2c are: a. DiagramCompositeClass - DiagramCompositeClass is used as a top-level class for a composite class diagram when it is not possible to use an architectural element as the toplevel class. This usually arises when connections are required between two classes which are at the top level - which is not generally possible. In such a case, the two top-level architectural elements would be properties of the DiagramCompositeClass, enabling connections to be made between the properties. b. NestedConnectorEnd - To maintain compatibility with the SysML standard ( MODAF has tried to re-use as many of the SysML stereotypes as possible. c. Node - A logical entity which creates, consumes or manipulates information. A <<Node>> is a usually grouping of organizations and systems (and other nodes) for a particular purpose. d. Resource - Something that is able to supply functionality, information or material. MODAF-M7-022 Version

113 e. ResourceForNode - An assertion that a resource is provided to a node. If resourceisnode is true then the resource itself is the node - e.g. an "Aircraft Carrier" <<System>> could be the "Maritime Ops Control" <<Node>>, or a "Spot Team" <<Organisation>> could be the "Forward Observation" <<Node>> f. System - A coherent combination of physical artefacts, energy and information, assembled for a purpose. g. SystemPort - An interface (logical or physical) provided by a <<System>>. A <<SystemPort>> may implement a <<PortType>>, though there is no requirement for SystemPorts to be typed. h. SystemPortConnector - Asserts that a connection exists between two ports belonging to parts in a system composite structure model. i. SystemPortConnectorEnd - The end of a connector between system ports. MODAF-M7-022 Version

114 7.3 Systems-Systems Matrix (SV-3) SV-3 Product Description Product Definition 318. The Systems-Systems Matrix provides detail on the interface characteristics described in SV-1 for the Architecture, arranged in matrix form Product Purpose 319. An SV-3 Product allows a quick overview of all the interface characteristics presented in multiple SV-1 diagrams. The matrix form can support a rapid assessment of potential commonalities and redundancies (or, if fault-tolerance is desired, the lack of redundancies) An SV-3 Product can be organised in a number of ways (e.g., by domain, by operational mission phase) to emphasise the association of groups of system pairs in context with the Architecture purpose. SV-3 can be a useful tool for managing the evolution of systems and system infrastructures, the insertion of new technologies/functionality, and the redistribution of systems and processes in context with evolving operational requirements Detailed Product Description 321. SV-3 is a summary description of the system-system interfaces identified in SV-1. SV-3 is similar to an N 2 -type matrix, where the systems are listed in the rows and columns of the matrix, and each cell indicates a system pair interface, if one exists. Many types of interface information can be presented in the cells of SV-3. The system interfaces can be represented using a number of different symbols and/or colour codes that depict different interface characteristics. MODAF does not specify the symbols to be used, but if it is used, the SV-3 table must provide a key to the symbols. The following are examples: a. Status (e.g., existing, planned, potential, deactivated) b. Purpose c. Classification level d. Means e. Standard f. Key Interface MODAF-M7-022 Version

115 322. Figure 7-14 provides a template for SV-3. Each cell may contain several interface characteristics, but this is not shown in the notional example provided below. Figure 7-14: Systems-Systems Matrix (SV-3) Template SV-3 UML Representation 323. There is no specific UML diagram that is applicable to the SV-3 View SV-3 MODAF Meta Model Support System (from MODAF::Systems) + child {redefines type} + parent {redefines class } SystemAssemblyUsage (from MODAF::Systems) {aggregation = composite} Property (from UML::CompositeStructures::InternalStructures) + connectioncontext {redefines role} SystemConnectorEnd (from MODAF::Systems) NestedConnectorEnd -propertypath:property[2..*ordered] 2 {subsets end} Resource SystemConnector (from MODAF::Systems) ConnectorEnd (from UML::CompositeStructures::InternalStructures) Class (from UML::CompositeStructures::StructuredClasses) Connector (from UML::CompositeStructures::InternalStructures) Figure 7-15: MODAF Meta Model Extract for SV-3 MODAF-M7-022 Version

116 324. An SV-3 product is a summary of the system-to-system connections described in an SV-1 product. To represent this information, the M 3 elements used by SV-3 are the same as SV-1 with the exception of nodes and physical properties The model elements used in SV-3 are: a. NestedConnectorEnd - To maintain compatibility with the SysML standard ( MODAF has tried to re-use as many of the SysML stereotypes as possible. b. Resource - Something that is able to supply functionality, information or material. c. System - A coherent combination of physical artefacts, energy and information, assembled for a purpose. d. SystemAssemblyUsage - Used to link a parent system to its sub-systems. Only <<SystemAssemblyUsage>> may be used to represent a system-subsystem relationship. e. SystemConnector - Asserts that a connection exists between two parts in a system composite structure model. f. SystemConnectorEnd - The end of a connector between systems - note that when port-to-port connections are to be specified, <<SystemPortConnectorEnd>> should be used. MODAF-M7-022 Version

117 7.4 Systems Functionality Description (SV-4) SV-4 Product Description Product Definition 326. The Systems Functionality Description documents system functional hierarchies and system functions, and the system data flows between them. Although there is a correlation between the Operational Activity Model (OV-5) or business-process hierarchies and the system functional hierarchy of SV-4, it need not be a one-to-one mapping, hence, the need for the Operational Activity to Systems Function Traceability Matrix (SV-5), which provides that mapping Product Purpose 327. The primary purposes of SV-4 are to: a. develop a clear description of the necessary system data flows that are input (consumed) by and output (produced) by each system b. ensure that the functional connectivity is complete (i.e. that a system s required inputs are all satisfied) c. ensure that the functional decomposition reaches an appropriate level of detail Detailed Product Description 328. An SV-4 Product describes system functions and the flow of system data among system functions. It is the SV counterpart to OV-5. SV-4 may be represented in a format similar to data flow diagrams. The scope of this Product may be enterprise wide, without regard to which systems perform which functions, or it may be system specific. Variations may focus on intranodal system data flow, internodal system data flow, system data flow without Node considerations, function to system allocations, and function to Node allocations System functions are not limited to internal system functions and can include Human Computer Interface (HCI) and Graphical User Interface (GUI) functions or functions that consume or produce system data from/to system functions that belong to external systems. The external system data sources and/or sinks can be used to represent the human that interacts with the system or external systems. The system data flows between the external system data source/sink (representing the human or system) and the HCI, GUI, or interface function can be used to represent human-system interactions, or system-system interfaces. Standards that apply to system functions, such as HCI and GUI standards, are also specified in this Product Like OV-5, SV-4 may be hierarchical in nature and may have both a hierarchy or decomposition model and a system data flow model. The hierarchy model documents a functional decomposition. The functions decomposed are system functions. Figure 7-16 shows a template for a functional decomposition model of SV-4. MODAF-M7-022 Version

118 Figure 7-16: Systems Functionality Description (SV-4) Template (Functional Decomposition) 331. SV-4 documents system functions, the flows of system data between those functions, the internal system data repositories or system data stores, and the external sources and sinks for the system data flows. It may represent external systems or the humans that interact with the system function. External sources and sinks represent sources external to the diagram scope but not external to the Architecture scope. Figure 7-17 shows a template for the data flow diagram of SV-4. The ovals represent system functions at some consistent level of decomposition, the squares are external system data sources and sinks, and the arrows represent system data flows. Internal system data repositories are represented by parallel lines. SV-4s can be arranged hierarchically, with each system function at the parent level being decomposed into a child SV-4 at the next level. Figure 7-17: Systems Functionality Description (SV-4) Template (Data Flow Diagram) MODAF-M7-022 Version

119 7.4.2 SV-4 UML Representation 332. UML activity diagrams can be used to show systems functions and the flow of data between them, as shown in Figure <<SystemFunction>> Image Processing Raw Image (TIFF) RectifyImage Rectified Image (TIFF) Threshold Analysis Enhancement Enhanced Image (TIFF) Pixel Classification Enhancement Processed Image (TIFF) Figure 7-18 UML diagram for SV Optionally, use cases (see Figure 7-19) may be used to provide additional information, however these would be purely informative only activity models represent the normative information captured in an SV-4 product. As UML Activities are also classes, it is possible to show functional breakdowns as class diagrams. Figure 7-19: UML Use Case Diagram for Systems Functionality Description (SV-4) MODAF-M7-022 Version

120 7.4.3 SV-4 MODAF Meta Model Support Activities (from UML) Activity (from UML::Activities::BasicActivities) SystemFunction (from MODAF::Systems) -systemusagecontext:property Actions (from UML) Usage (from UML::Classes::Dependencies) + performingsystem {redefines context} System (from MODAF::Systems) ObjectFlow (from UML::Activities::BasicActivities) + flow {redefines client} SystemConnectionToFlowMapping (from MODAF::Systems) Resource + systemconnection {redefines supplier} AssociationClass (from UML::Classes::AssociationClasses) SystemConnectionSpecification (from MODAF::Systems) Class (from UML::CompositeStructures::StructuredClasses) Figure 7-20: MODAF Meta Model Excerpt for SV Unlike OV-5, there is no requirement to constrain UML activity diagrams in SV-4 - because these types of diagrams are best in class for modelling system functional behaviour. As a result, only the activity metaclass is stereotyped to <<SystemFunction>>. Because all Operational Activity elements shall be stereotyped, there is no danger of confusing operational activities with system functions Any element from the UML::Activities and UML::Actions packages may be used in an SV-4, provided that activities are stereotyped as <<SystemFunction>> A <<SystemFunction>> shall be related to the system that performs the function via the redefined context relationship. It is possible to model a function being performed by a particular usage of a system by setting the systemusagecontext attribute to point at the usage property. This enables modelling of system functions across system boundaries when multiple systems of the same type are deployed in an architecture - e.g. several comms systems of the same type being used by different nodes Although not generally shown on an SV-4, the M 3 also enables traceability from functional flows to the system connections that realise those flows via <<SystemConnectionToFlowMapping>> 338. The model elements used in SV-4 are: a. Resource - Something that is able to supply functionality, information or material. MODAF-M7-022 Version

121 b. System - A coherent combination of physical artefacts, energy and information, assembled for a purpose. c. SystemConnectionSpecification - Asserts that a relationship is possible between two types of systems. <<SystemConnectionSpecification>> AssociationClass so that properties may be assigned to the connection (<<SystemConnector>>) that instantiates the relationship. d. SystemConnectionToFlowMapping - Asserts that a system connection carries an ObjectFlow which flows between system functions. e. SystemFunction - A automated process carried out by a system or system of systems. If the process is carried out only by a specific usage of a system, the systemusagecontext property points to the property which is typed by the system class in a composite structure model. MODAF-M7-022 Version

122 7.5 Operational Activity to Systems Function Traceability Matrix (SV-5) SV-5 Product Description Product Definition 339. An Operational Activity to Systems Function Traceability Matrix is a specification of the relationships between the set of operational activities applicable to an Architecture and the set of system functions applicable to that Architecture Product Purpose 340. An SV-5 Product depicts the mapping of operational activities to system functions and thus identifies the transformation of an operational need into a purposeful action performed by a system i.e. how the system function supports the conducting of the Operational activity. SV-5 can be extended to depict the mapping of capabilities to operational activities, operational activities to system functions, system functions to systems, and thus relates the capabilities to the systems that support them. Such a matrix, in conjunction with StV-3,5 & 6, allows decision makers and planners to quickly identify stovepiped systems, redundant/duplicative systems, gaps in military capability, and possible future investment strategies all in accordance with the time stamp given to the Architecture. SV-5 correlates capability requirements that would not be satisfied if a specific system is not fielded to a specific unit Detailed Product Description 341. The Framework uses the terms activity in the OVs and function in the SVs to refer to essentially the same kind of thing both activities and functions are tasks that are performed, accept inputs, and develop outputs. The distinction lies in the fact that system functions are executed by automated systems, while operational activities describe business operations that may be conducted by humans, automated systems, or both. Typical systems engineering practices use both of these terms, often interchangeably. However, given the Framework s use of activities on the operational side and functions on the systems side, and the fact that Operational Nodes do not always map one-to-one to systems Nodes, it is natural that operational activities do not map one-to-one to system functions. Therefore, SV-5 forms an integral part of the eventual complete mapping from operational capabilities to systems requirements. SV-5 is an explicit link between the OV and SV. The capabilities and activities are drawn from OV-5, OV-6b, and OV-6c. The system functions are drawn from an SV-4. (SV-1 and SV-2 may also define system functions for identified systems.) 342. The relationship between operational activities and system functions can also be expected to be many-to- many (i.e., one Operational Activity may be supported by multiple system functions, and one system function may support multiple operational activities). Figure 7-21 provides a notional example of SV-5. MODAF-M7-022 Version

123 Operational Activity Recce Collate Intelligence Conduct Estimate Co-ordinate Plan Attack Re-cuperate SPECS 2 Functions Provision Of Real-Time Video Imagery X X X X Provision Of Real-Time IR Imagery X X X X Monitoring Of Airspace X X X Timelapse Recording Of Designated Areas X X Communications Relay X X X X X X Command & Control X X Figure 7-21: Operational Activity to Systems Function Traceability Matrix (SV-5) 343. A key element of operational requirement traceability is the relation of system functions and operational activities to systems and capabilities. A capability may be defined in terms of the attributes required to accomplish a set of activities (such as the sequence and timing of activities, and the materiel that support them) in order to achieve a given mission objective Capability-related attributes may be associated with specific activities or with the information exchange between activities, or both. A particular operational thread may be used to depict a military capability. An operational thread is defined as a set of operational activities, with sequence and timing attributes of the activities, and includes the information needed to accomplish the activities. In this manner, a capability is defined in terms of the attributes required to accomplish a given mission objective by modelling the set of activities and their attributes. SV-5 can be used to map capabilities to operational activities, operational activities to system functions, and system functions to systems, and thus relate the capabilities to the systems that support them First, the activities are related to the system functions that automate them (wholly or partially). Then a set of activities are associated with a capability (as defined in OV-6c). By labelling the system functions with the systems that execute them (as defined in SV-1, SV-2, and SV-4), SV-5 can be used as the planner s matrix for analyses and decision support. The traceability from capabilities/activities to system/system functions is described by populating the SV-5 matrix Each mapping between an Operational Activity to a system function is described by a stoplight coloured circle to indicate the status of the system support. Red indicates functionality planned but not developed. Yellow indicates partial functionality provided or full functionality provided but system has not been fielded. Green indicates full functionality MODAF-M7-022 Version

124 provided and system fielded. A blank cell indicates that there is no system support planned for an Operational Activity, or that a relationship does not exist between the Operational Activity and the system function. In this manner, the association between a certain capability and a specific system can be illustrated via a many-to-many relationship: many operational activities contribute to a capability, and many system functions are executed by a system. Figure 7-22 provides a notional example of the extended SV-5 that provides a mapping between capabilities and systems. Figure 7-22: Capability to System Traceability Matrix (SV-5) SV-5 UML Representation 347. There is no specific UML diagram that is applicable to the SV-5 View SV-5 MODAF Meta Model Support MODAF-M7-022 Version

125 Class (from UML::CompositeStructures::StructuredClasses) Resource System (from MODAF::Systems) SystemFunction (from MODAF::Systems) + performingsystem {redefines context} -systemusagecontext:property + function {redefines supplier} Activity (from UML::Activities::BasicActivities) ActivityToFunctionMapping (from MODAF::Systems) Usage (from UML::Classes::Dependencies) + activity {redefines client} Capability (from MODAF::Capabilities) OperationalActivity (from MODAF::Operational) + performedactivity { redefines client} + enablingcapability {redefines supplier} PerformanceEnabler (from MODAF::Capabilities) Figure 7-23: MODAF Meta Model Excerpt for SV The key element in an SV-5 is <<ActivityToFunctionMapping>> which links an <<OperationalActivity>> to the <<SystemFunction>> that supports it. The <<System>> which performs the function may be shown. In some cases it is also useful to show the <<Capability>> that is enabled by the <<OperationalActivity>> 349. The model elements used in SV-5 are: a. ActivityToFunctionMapping - Asserts that a <<SystemFunction>> (at least in part) performs or assists in the conducting of an <<OperationalActivity>>. b. Capability - A high level user requirement, usually functional. A capability may have performance metrics represented as Physical Properties. Note that some capabilities might be called "Capability Functions" - MODAF does not distinguish between Capability Functions and Capabilities, other than by virtue of their position in a hierarchy, defined by <<CapabilityComposition>> MODAF-M7-022 Version

126 c. OperationalActivity - A process carried out by a person or organisation - i.e. not an automated function. d. PerformanceEnabler - The <<PerformanceEnabler>> stereotype links an <<OperationalActivity>> to a <<Capability>> that enables/supports its execution. e. Resource - Something that is able to supply functionality, information or material. f. System - A coherent combination of physical artefacts, energy and information, assembled for a purpose. g. SystemFunction - A automated process carried out by a system or system of systems. If the process is carried out only by a specific usage of a system, the systemusagecontext property points to the property which is typed by the system class in a composite structure model. MODAF-M7-022 Version

127 7.6 Systems Data Exchange Matrix (SV-6) SV-6 Product Description Product Definition 350. The Systems Data Exchange Matrix specifies the characteristics of the system data exchanged between systems. This Product focuses on automated information exchanges (from OV-3) that are implemented in systems. Non-automated information exchanges, such as verbal orders, are captured in the OV Products only Product Purpose 351. System data exchanges express the relationship across the three basic Architecture data elements of an SV (systems, system functions, and system data flows) and focus on the specific aspects of the system data flow and the system data content. These aspects of the system data exchange can be crucial to the operational mission and are critical to understanding the potential for overhead and constraints introduced by the physical aspects of the implementation Detailed Product Description 352. SV-6 describes, in tabular format, system data exchanged between systems. The focus of SV-6 is on how the system data exchange is implemented, in system-specific details covering periodicity, timeliness, throughput, size, information assurance, and security characteristics of the exchange. In addition, the system data elements, their format and media type, accuracy, units of measurement, and system data standard are also described in the matrix SV-6 relates to, and grows out of, OV-3. The operational characteristics for the OV-3 information exchange are replaced with the corresponding system data characteristics. For example, the Levels of Information Systems Interoperability (LISI) level required for the operational information exchange is replaced by the LISI level achieved through the system data exchange(s). Similarly, performance attributes for the operational information exchanges are replaced by the actual system data exchange performance attributes for the automated portion(s) of the information exchange On SV-6, each operational Needline is decomposed into the interfaces that are the systems equivalents of the Needline. SV-1 graphically depicts system data exchanges as interfaces that represent the automated portions of the Needlines. The implementation of SV- 1 interfaces is described in SV-2 (if applicable). The system data exchanges documented in SV-6 trace to the information exchanges detailed in OV-3 and constitute the automated portion(s) of the OV-3 information elements Figure 7-24 shows an example for this Product. The data element definition table for SV-6 contains detailed descriptions or references for each matrix column. MODAF-M7-022 Version

128 Data Exchange ID Sending System Receiving System Data Content Media Type Data Format Criticality 1 ISTAR BASE STATION COMMAND & CONTROL SPECS 2 COMMAND & CONTROL SPECS 2 TASK SECURE ELECTRONIC MESSAGE STRUCTURED ALPHA- NUMERIC HIGH 2 SPECS 2 COMMAND & CONTROL ISTAR BASE STATION COMMAND & CONTROL ENEMY POSITION & MOVEMENT REAL-TIME VISUAL IMAGERY MPG MEDIUM 3 SPECS 2 COMMAND & CONTROL ISTAR BASE STATION COMMAND & CONTROL ENEMY POSITION & MOVEMENT REAL-TIME IR IMAGERY MPG MEDIUM 4 SPECS 2 COMMAND & CONTROL ISTAR BASE STATION COMMAND & CONTROL BANDWIDTH CAPACITY ELECTRONIC MESSAGE NUMERIC LOW 5 SPECS 2 COMMAND & CONTROL ISTAR BASE STATION COMMAND & CONTROL ENEMY POSITION & MOVEMENT STRUCTURED REPORT ENEMY LOCATION AND SPEED META DATA HIGH 6 SPECS 2 COMMAND & CONTROL ISTAR BASE STATION COMMAND & CONTROL ENEMY STATUS CHANGE ALERT SECURE ELECTRONIC MESSAGE REPORT CHANGE METIRCS HIGH Figure 7-24: Systems Data Exchange Matrix (SV-6) Template 356. It should be noted that each system data element exchanged is related to the system function (from SV-4) that produces or consumes it via the leaf inputs and outputs of the system functions However, there may not be a one-to-one correlation between system data elements listed in the matrix and the data flows (inputs and outputs) that are produced or consumed in a related SV System data inputs and outputs between system functions performed at the same systems Node (i.e., not associated with an interface on SV-1) will not be shown in the SV-6 matrix. System data inputs and outputs between functions for some levels of functional decomposition may be at a higher level of abstraction than the system data elements in the SV-6 matrix. In this case, multiple system data elements will map to a single function s system data flow. Similarly, the system data flows between functions at a low level of functional decomposition may be at a finer level of detail than the system data elements in the SV-6 matrix, and multiple system data flows may map to a single system data element SV-6 UML Representation 359. There is no specific UML diagram that is applicable to the SV-6 View. MODAF-M7-022 Version

129 7.6.3 SV-6 MODAF Meta Model Support Realization (from UML::Classes::Dependencies) ConnectionRealisesIER (from MODAF::Systems) + ier { redefines client} InformationExchange (from MODAF::Operational) SystemConnector (from MODAF::Systems) + connection { redefines supplier} -requirementtext:string Connector (from UML::CompositeStructures::InternalStructures) { subsets type} SystemConnectionSpecification (from MODAF::Systems) AssociationClass (from UML::Classes::AssociationClasses) InformationFlow (from UML::AuxiliaryConstructs::InformationFlows) PropertyAssignedItem + assigneditem { redefines class} PhysicalProperty -maxvalue:literalspecification[0..1] -minvalue:literalspecification[0..1] + uom { redefines datatype } UnitOfMeasure Class (from UML::Classes::Kernel) Property (from UML::Classes::Kernel) DataType (from UML::Classes::Kernel) Figure 7-25: MODAF Meta Model Extract for SV SV-6 presents information about system connectivity derived from SV-1, but with additional information, such as attributes and properties. If the information is a measurable physical property of the system connection, then the <<PhysicalProperty>> stereotype should be used - otherwise, non-stereotyped UML properties should be used An SV-6 table is usually sorted by IERs (Information Exchange Requirements, described initially in OV-3). To do this, it is necessary to map the <<SystemConnector>> connectors to the <<InformationExchange>> InformationFlows that they realise. This is archived with the <<ConnectionRealisesIER>> stereotype The model elements used in SV-6 are: a. ConnectionRealisesIER - Asserts that the information exchange requirement (IER) specified by a <<InformationExchange>> is at least partially met by a <<SystemConnection>>. It may require several connections to realise a single IER. b. InformationExchange - A specification of the information that is to be exchanged. c. PhysicalProperty - A property of something in the physical world, expressed in amounts of a unit of measure. The property may have a required value - either specified by MODAF-M7-022 Version

130 the defaultvalue from uml::property attribute, or the minvalue and maxvalue to specify a required range. d. PropertyAssignedItem - The abstract superclass of all classes which may have physical properties e. SystemConnectionSpecification - Asserts that a relationship is possible between two types of systems. <<SystemConnectionSpecification>> AssociationClass so that properties may be assigned to the connection (<<SystemConnector>>) that instantiates the relationship. f. SystemConnector - Asserts that a connection exists between two parts in a system composite structure model. g. UnitOfMeasure - A determinate amount or quantity adopted as a standard of measurement for other amounts or quantities of the same kind. MODAF-M7-022 Version

131 7.7 Systems Performance Parameters Matrix (SV-7) SV-7 Product Description Product Definition 363. The Systems Performance Parameters Matrix Product specifies the quantitative characteristics of systems and system hardware/software items, their interfaces (system data carried by the interface as well as communications link details that implement the interface), and their functions. It specifies the current performance parameters of each system, interface, or system function, and the expected or required performance parameters at specified times in the future. The performance parameters are selected by the architect and end user community Performance parameters include all technical performance characteristics of systems for which requirements can be developed and specification defined. The complete set of performance parameters may not be known at the early stages of Architecture definition, so it is to be expected that this Product will be updated throughout the system s specification, design, development, testing, and possibly even its deployment and operations life-cycle phases Product Purpose 365. One of the primary purposes of SV-7 is to communicate which characteristics are considered most crucial for the successful achievement of the mission goals assigned to the system. These particular parameters can often be the deciding factors in acquisition and deployment decisions, and will figure strongly in systems analyses and simulations done to support the acquisition decision processes and system design refinement Detailed Product Description 366. SV-7 builds on SV-1, SV-2, SV-4, and SV-6 by specifying performance parameters for systems and system hardware/software items and their interfaces (defined in SV-1), communications details (defined in SV-2), their functions (defined in SV-4), and their system data exchanges (defined in SV-6). The term system, as defined for this Product and all others in the Framework, may represent a FoS, SoS, Network of systems, or an individual system. Performance parameters for system hardware/software items (the hardware and software elements comprising a system) are also described in this Product. In addition, performance parameters often relate to a system function being performed. Therefore, system functions and their performance attributes may also be shown in this Product. If the future performance expectations are based on expected technology improvements, then the performance parameters and their time periods will be coordinated by using a Systems Technology Forecast (SV-9). If performance improvements are associated with an overall system evolution or migration plan, then the time periods in SV-7 will be coordinated with the milestones in a Systems Evolution Description (SV-8). Figure 7-26 is a template of SV-7, listing notional user defined performance characteristics with a time period association. It should be noted that these are example metrics. MODAF-M7-022 Version

132 Figure 7-26: Systems Performance Parameters Matrix (SV-7) Notional Example SV-7 UML Representation 367. There is no specific UML diagram that is applicable to the SV-7 View SV-7 MODAF Meta Model Support Property (from UML::CompositeStructures::InternalStructures) Class (from UML::CompositeStructures::StructuredClasses) Resource DataType (from UML::Classes::Kernel) UnitOfMeasure SystemAssemblyUsage (from MODAF::Systems) {aggregation = composite} + parent {redefines class} + child {redefines type} System (from MODAF::Systems) {redefines datatype } + uom PropertyAssignedItem + assigneditem {redefines class} PhysicalProperty -maxvalue:literalspecification[0..1] Property (from UML::Classes::Kernel) 12 The terms Maintainability, Availability and Effectiveness are used only to illustrate this view and are not meant to convey the specific meaning attributed to them by MoD specialist communities. MODAF-M7-022 Version

133 Figure 7-27: MODAF Meta Model Extract for SV SV-7 presents information about systems and their sub-systems (e.g. hardware and software components), such as attributes and properties. If the information is a measurable physical property of the system (e.g. response time), then the <<PhysicalProperty>> stereotype should be used - otherwise, non-stereotyped UML properties should be used The model elements used in SV-7 are: a. PhysicalProperty - A property of something in the physical world, expressed in amounts of a unit of measure. The property may have a required value - either specified by the defaultvalue from uml::property attribute, or the minvalue and maxvalue to specify a required range. b. PropertyAssignedItem - The abstract superclass of all classes which may have physical properties c. Resource - Something that is able to supply functionality, information or material. d. System - A coherent combination of physical artefacts, energy and information, assembled for a purpose. e. SystemAssemblyUsage - Used to link a parent system to its sub-systems. Only <<SystemAssemblyUsage>> may be used to represent a system-subsystem relationship. f. UnitOfMeasure - A determinate amount or quantity adopted as a standard of measurement for other amounts or quantities of the same kind. MODAF-M7-022 Version

134 7.8 Systems Evolution Description (SV-8) SV-8 Product Description Product Definition 370. The Systems Evolution Description captures evolution plans that describe how the system, or the Architecture in which the system is embedded, will evolve over a lengthy period of time. Generally, the timeline milestones are critical for a successful understanding of the evolution timeline Product Purpose 371. SV-8, when linked together with other evolution Products such as AcV-2, SV-9 and TV- 2, provides a clear definition of how the Architecture and its systems are expected to evolve over time. In this manner, the Product can be used as an Architecture evolution project plan or transition plan Detailed Product Description 372. An SV-8 Product describes plans for modernising system functions over time. Such efforts typically involve the characteristics of evolution (spreading in scope while increasing functionality and flexibility) or migration (incrementally creating a more streamlined, efficient, smaller, and cheaper suite) and will often combine the two thrusts. This Product builds on other Products and analyses in that planned capabilities and information requirements that relate to performance parameters (of SV-7) and technology forecasts (of SV-9) are accommodated in this Product. The template for SV-8 consists of two generic examples. If the Architecture describes a communications infrastructure, then a planned evolution or migration of communications systems, communication links, and their associated standards can also be described in this Product. Figure 7-28 illustrates a migration description, while Figure 7-29 illustrates evolution. All entries in the graphics are for illustration only. Figure 7-28: Systems Evolution Description (SV-8) Migration MODAF-M7-022 Version

135 Figure 7-29: Systems Evolution Description (SV-8) Evolution SV-8 UML Representation 373. There is no specific UML diagram that is applicable to the SV-8 View. MODAF-M7-022 Version

136 7.8.3 SV-8 MODAF Meta Model Support Resource Class (from UML::CompositeStructures::StructuredClasses) System (from MODAF::Systems) ProjectType (from MODAF::Projects) + typeofproject { redefines Classifier} Project (from MODAF::Projects) -predictedstartdate:timeevent -predictedenddate:timeevent { redefines supplier} + deliveredsystem Dependency (from UML::Classes::Dependencies) InstanceSpecification (from UML::Classes::Kernel) SystemStatusAtMilestone (from MODAF::Systems) -actualstatus:string[0..1] -predictedstatus:string + deliverymilestone { redefines client} ProjectMilestone (from MODAF::Projects) SystemDeliveryAtMilestone (from MODAF::Systems) -systemversion:string TimeEvent (from UML::CommonBehaviors::Communications) Figure 7-30: MODAF Meta Model Excerpt for SV The timeline of an SV-8 is represented as a <<Project>>. The events in the timeline are represented by <<ProjectMilestone>> events. A system status may be defined at any given milestone (usually, the milestone is created to represent an event in the lifecycle of the system) using the <<SystemStatusAtMilestone>>. To represent the delivery of a system, or of a new version of a system, the <<SystemDelivertyAtMileston>> stereotype is used The model elements used in SV-8 are: a. Project - A plan, proposal or scheme for a task (or series of tasks) that takes place over a finite duration b. ProjectMilestone - An event in a project by which progress is measured. c. ProjectType - A category of <<Project>> - e.g. "Programme", "Acquisition Project", etc. d. Resource - Something that is able to supply functionality, information or material. MODAF-M7-022 Version

137 e. System - A coherent combination of physical artefacts, energy and information, assembled for a purpose. f. SystemDeliveryAtMilestone - Asserts that a System (at a given version) is to be delivered at the time specified by a ProjectMilestone. g. SystemStatusAtMilestone - Describes the actual or predicted status of a System at a <<ProjectMilestone>> - i.e. a point in the lifecycle of the system. MODAF-M7-022 Version

138 7.9 Systems Technology Forecast (SV-9) SV-9 Product Description Product Definition 376. The Systems Technology Forecast defines the underlying current and expected supporting technologies. It is not expected to include predictions of technologies. Expected supporting technologies are those that can be reasonably forecast given the current state of technology and expected improvements. New technologies will be tied to specific time periods, which can correlate against the time periods used in SV-8 milestones Product Purpose 377. SV-9 provides a summary of emerging technologies that impact the Architecture and its existing planned systems. The focus will be on the supporting technologies that may most affect the capabilities of the Architecture or its systems Detailed Product Description 378. SV-9 provides a detailed description of emerging technologies and specific hardware and software Products. It contains predictions about the availability of emerging technological capabilities and about industry trends in specific time periods. The specific time periods selected (e.g., 6-month, 12-month, 18- month intervals) and the technologies being tracked will be coordinated with Architecture transition plans (see SV-8). That is, insertion of new technological capabilities and upgrading of existing systems may depend on or be driven by the availability of new technology. The forecast includes potential technology impacts on current Architectures and thus influences the development of transition and objective (i.e., target) Architectures. The forecast will be focused on technology areas that are related to the purpose for which a given Architecture is being described and will identify issues affecting that Architecture. If standards are an integral part of the technologies important to the evolution of a given Architecture, then it may be convenient to combine SV-9 with the Technical Standards Forecast (TV-2) SV-9 is constructed as part of a given Architecture and in accordance with the Architecture purpose. Typically, this will involve starting with one or more overarching reference models or standards profiles to which the Architecture is subject to using. Using these reference models or standards profiles, the architect will select the service areas and services relevant to the Architecture. SV-9 forecasts relate to the Technical Standards Profile (TV-1) in that a timed technology forecast may contribute to the decision to retire or phase out the use of a certain standard in connection with a system element. Similarly, SV-9 forecasts relate to TV-2 standards forecasts in that a certain standard may be adopted depending on a certain technology becoming available (e.g., the availability of Java Script may influence the decision to adopt a new HTML standard). MODAF-M7-022 Version

139 380. An example for SV-9 is shown in Figure Area Short Term 1-3 years Medium Term 3-6 years Long Term 6-9 years Default digital signal processor speeds 2Ghz Processor 10Ghz Processor Default storage capacity for Personal Computer 60GB 180GB Networking philosophy Fixed Point To Point Networks Virtual Networks (including VLAN) Service Orientated Networking Windows Version XP XP Not disclosed Figure 7-31: Systems Technology Forecast (SV-9) Notional Example 381. Alternatively, SV-9 may relate technology forecasts to SV elements (e.g., systems) where applicable. The list of systems potentially impacted by the technology can be included directly in SV-9 by specifying a time period in the cell corresponding to the system element and the applicable service area and service. Figure 7-32 is a template showing this variant of SV-9. Systems (includes SOS, FOS, Subsystem, Communications Systems Hardware or Software Item Communications (Physical) Link System Function System Data Element Model Standard or Source JTA Service Area Service Technology Forecast (Summary Prediction) Applicable System ID or Name (with Time Period if applicable) Hardware or Software ID or Name, Version (with Time Period if applicable) System Data Link ID or Name (with Time Period if applicable) System Function ID or Name System Data Exchange ID or Name (with Time Period if applicable) Model Standard or Source ID or Name (with Time Period if applicable) Figure 7-32: Systems Technology Forecast (SV-9) Template SV-9 UML Representation 382. There is no specific UML diagram that is applicable to the SV-9 View. MODAF-M7-022 Version

140 7.9.3 SV-9 MODAF Meta Model Support Property (from UML::CompositeStructures::InternalStructures) ResourceForCapability (from MODAF::Capabilities) Class (from UML::CompositeStructures::StructuredClasses) + resource {redefines type} CapabilityComposition (from MODAF::Capabilities) + parentcapability {redefines class} + childcapability {redefines type} Capability (from MODAF::Capabilities) Resource + fulfilledcapability {redefines client} + capability {redefines class } Usage (from UML::Classes::Dependencies) CapabilityFulfilment (from MODAF::Capabilities) {subsets supplier} FieldedCapability (from MODAF::Capabilities) System (from MODAF::Systems) -doctrine:constraint[1..*] EffectivityConstrainedItem {subsets constraineditem} EffectivityConstraint Constraint (from UML::Classes::Kernel) Interval (from UML::CommonBehaviors::SimpleTime) + effectivityperiod {redefines specification} TimePeriod Figure 7-33: MODAF Meta Model Extract for SV SV-9 presents the similar information as StV-3, but in a slightly different format. SV-9 has more of a technology capability focus, whereas StV-3 is defining business or war-fighting capabilities, but the same meta model approach can be used for both views The model elements used in SV-9 are: a. Capability - A high level user requirement, usually functional. A capability may have performance metrics represented as Physical Properties. Note that some capabilities might be called "Capability Functions" - MODAF does not distinguish between Capability Functions and Capabilities, other than by virtue of their position in a hierarchy, defined by <<CapabilityComposition>> b. CapabilityComposition - A parent-child relationship between two capabilities i.e. the relationship indicates one capability (child) is a sub-capability of the other (parent). Although the MOD tends to work in terms of capabilities and capability functions, it is not always apparent that there is any difference between them other than their relative positions in a capability taxonomy, which is specified by the <<CapabilityComposition>> relationship. Note: The initial intention was to re-use the SysML <<Requirement>> stereotype specialised to <<Capability>>. However, the nested-classifier approach used in SysML MODAF-M7-022 Version

141 does not lend itself to the reality of MOD Capability development where the same capability function may appear in different places in the capability hierarchy. It is also clear from the SysML documentation that <<Requirement>> is purely a System Requirement, which precludes its use for CRD and URD purposes. c. CapabilityFulfilment - An assertion that a capability can be met by a <<FieldedCapability>>. d. EffectivityConstrainedItem - An item whose existence is contrained by an <<EffectivityConstraint>> - i.e. something which is valid for a time period. e. EffectivityConstraint - Specifies that the constraineditem has a time-based existence (effectivity) f. FieldedCapability - A combination of organisational aspects (with their competencies) and equipment that combine to provide a capability. A <<FieldedCapability>> must be guided by doctrine which may take the form of <<Standard>> or <<OperationalConstraint>> stereotypes g. Resource - Something that is able to supply functionality, information or material. h. ResourceForCapability - Relates a <<FieldedCapability>> to a resource that contributes towards achieving the capability - e.g. a type of system operated by an organisation with the appropriate competence. i. System - A coherent combination of physical artefacts, energy and information, assembled for a purpose. j. TimePeriod - A period of time, defined by start and end dates - sometimes termed an "Epoch" in the MOD. Time periods may overlap. MODAF-M7-022 Version

142 7.10 Systems Functionality Sequence & Timing Description (SV-10a, 10b, & 10c) Overview of Systems Functionality Sequence and Timing Descriptions (SV-10A, 10B, & 10C) 385. Many of the critical characteristics of an Architecture are only discovered when an Architecture s dynamic behaviours are defined and described. These dynamic behaviours concern the timing and sequencing of events that capture system performance characteristics of an executing system (i.e., a system performing the system functions described in SV-4). Behaviour modelling and documentation is key to a successful Architecture description, because it is how the Architecture behaves that is crucial in many situations. Although knowledge of the functions and interfaces is also crucial, knowing whether, for example, a response should be expected after sending message X to Node Y can be crucial to successful overall operations Three types of models may be used to adequately describe the dynamic behaviour and performance characteristics of a SV. These three models are: a. Systems Rules Model (SV-10a) b. Systems State Transition Description (SV-10b) c. Systems Event-Trace Description (SV-10c) 387. SV-10b and SV-10c may be used separately or together, as necessary, to describe critical timing and sequencing behaviour in the SV. Both types of diagrams are used by a wide variety of different systems methodologies Both SV-10b and SV-10c describe systems responses to sequences of events. Events may also be referred to as inputs, transactions, or triggers. When an event occurs, the action to be taken may be subject to a rule or set of rules as described in SV-10a SV-10a Product Description Product Definition 389. Systems rules are constraints on an Architecture, on a system(s), or system hardware/software item(s), and/or on a system function(s). While other SV Products (e.g., SV-1, SV-2, SV-4, SV-11) describe the static structure of the System Viewpoint (i.e., what the systems can do), they do not describe, for the most part, what the systems must do, or what they cannot do At the systems or system hardware/software items level, SV-10a describes the rules under which the Architecture or its systems behave under specified conditions. At lower levels of decomposition, it may consist of rules that specify the pre- and post-conditions of system functions Product Purpose 391. The purpose of this Product is to allow understanding of behavioural rules and constraints imposed on systems and system functions Detailed Product Description 392. Rules are statements that define or constrain some aspect of the enterprise. In contrast to the Operational Rules Model (OV-6a), SV-10a focuses on constraints imposed by some MODAF-M7-022 Version

143 aspect of an enterprise requirement that translate into system performance requirements. At a lower level of detail, it focuses on some aspects of systems design or implementation. Thus, as the operational rules (OV-6a) can be associated with the Operational Activity Model (OV-5), the systems rules in SV-10a can be associated with SV-1 and SV-2 systems and hardware/software items or with SV-4 system functions. Systems rules can be expressed in natural language, as with OV-6a: a. Imperative a statement of what shall be under all conditions e.g. B shall be less than 6.0 b. Conditional Imperative a statement of what shall be, in the event of another condition being met If B is equal to 4 then A shall be true However, with potentially complex system rules it may be more useful to express these rules in Object Constraint Language (OCL) 13. Whichever language is used to describe the rules, it will be referenced and well documented (i.e., there will be text books or articles that describe it and provide examples of its use) SV-10a UML Representation 394. There is no specific UML diagram that is applicable to the SV-10a View. However, UML constraints are a direct analogue and have been stereotyped to SystemConstraint and these may be applied to other Products e.g. functions in SV-4: <<SystemFunction>> Image Processing Raw Image (TIFF) RectifyImage {duration < 10000} Rectified Image (TIFF) Threshold Analysis Enhancement {duration < 5000} Enhanced Image (TIFF) Pixel Classification Enhancement {duration < 3000} Processed Image (TIFF) Figure 7-34: OCL Example Embedded in an SV-4 Product 13 The language for defining rules and constraints for UML that is standardised through the Object Management Group MODAF-M7-022 Version

144 SV-10a MODAF Meta Model Support Constraint (from UML::Classes::Kernel) SystemConstraint (from MODAF::Systems) Figure 7-35: MODAF Meta Model Excerpt for SV-10a 395. A constraint on a system, a feature of a system or a function that a system performs. Because of the wide range of system elements that may legitimately be constrained, a <<SystemConstraint>> may be applied to anything to which a UML 2.0 constraint may be applied - i.e. UML:Element. This means that a system constrain may be applied to virtually every element defined by the M The model elements used in SV-10a are: a. SystemConstraint - A rule governing the structural or functional aspects of a system SV-10b Product Description Product Definition 397. The Systems State Transition Description is a graphical method of describing a system (or system function) response to various events by changing its state. The diagram basically represents the sets of events to which the systems in the Architecture will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action Product Purpose The explicit time sequencing of system functions in response to external and internal events is not fully expressed in SV-4. SV-10b can be used to describe the explicit sequencing of the system functions. Alternatively, SV-10b can be used to reflect explicit sequencing of the actions internal to a single system function, or the sequencing of system functions with respect to a specific system Basically, statechart diagrams can be unambiguously converted to structured textual rules that specify timing aspects of systems events and the responses to these events, with no loss of meaning. However, the graphical form of the state diagrams can often allow quick analysis of the completeness of the rule set, and detection of dead ends or missing conditions. These errors, if not detected early during the systems analysis phase, can often lead to serious behavioural errors in fielded systems, or to expensive correction efforts Detailed Product Description 400. SV-10b is based on the statechart diagram [OMG, 2003]. A state machine is defined as a specification that describes all possible behaviours of some dynamic model element. Behaviour is modelled as a traversal of a graph of state Nodes interconnected by one or more joined transition arcs that are triggered by the dispatching of series of event instances. During this traversal, the state machine executes a series of actions associated with various elements of the state machine. [OMG, 2003] MODAF-M7-022 Version

145 401. The Product relates states, events, and actions. A state and its associated action(s) specify the response of a system or system function, to events. When an event occurs, the next state may vary depending on the current state (and its associated action), the event, and the rule set or guard conditions. A change of state is called a transition. Each transition specifies the response based on a specific event and the current state. Actions may be associated with a given state or with the transition between states SV-10b can be used to describe the detailed sequencing of system functions described in SV-4. However, the relationship between the actions included in SV-10b and the system functions in SV-4 depends on the purposes of the Architecture and the level of abstraction used in the models. The explicit sequencing of system functions in response to external and internal events is not fully expressed in SV-4. SV-10b can be used to reflect explicit sequencing of the system functions, the sequencing of actions internal to a single function, or the sequencing of system functions with respect to a specific system Figure 7-36 provides a template for a simple SV-10b. The black dot and incoming arrow point to initial states (usually one per diagram), while terminal states are identified by an outgoing arrow pointing to a black dot with a circle around it. States are indicated by rounded corner box icons and labelled by name or number and, optionally, any actions associated with that state. Transitions between states are indicated by one-way arrows labelled with event/action notation, which indicates an event-action pair, and semantically translates to: when an event occurs, the corresponding action is executed. This notation indicates the event that causes the transition and the ensuing action (if any) associated with the transition. A more detailed example is shown in Figure Figure 7-36: Systems State Transition Description (SV-10b) High-Level Template SV-10b UML Representation 404. SV-10b may be produced in UML using statechart diagrams. Statechart diagrams contain simple states and composite states. They also contain transitions, which are described in terms of triggers or events. Image Processing Raw Image Received Rectifying Image Image Requires Further Rectification Rectified Image Ready Conducting Threshold Analysis Analysed Image Ready Conducting Pixel Classification Enhancement Image Requires Further Analysis Enhanced Image Ready Figure 7-37: UML Statechart Example MODAF-M7-022 Version

146 SV-10b MODAF Meta Model Support BehaviorStateMachines (from UML::StateMachines) StateMachine (from UML::StateMachines::BehaviorStateMachines) SystemStateMachine (from MODAF::Systems) { redefines context} SystemStateMachineOwner (from MODAF::Systems) Activity (from UML::Activities::BasicActivities) SystemFunction (from MODAF::Systems) System (from MODAF::Systems) -systemusagecontext:property Class (from UML::CompositeStructures::StructuredClasses) Resource Figure 7-38: MODAF Meta Model Excerpt for SV-10b 405. For OV-6b and SV-10b, the complete use of stereotyping has not been deemed necessary - UML state machines are ideal for representing these products. However, to constrain the use and enable a distinction between OV-6b and SV-10b state models, the UML:StateMachines:BehaviorStateMachines:StateMachine metaclass is stereotyped to <<OperationalStateDescription>> for OV-6b and <<SystemStateMachine>> for SV-10b 406. The model elements used in SV-10b are: a. Resource - Something that is able to supply functionality, information or material. b. System - A coherent combination of physical artefacts, energy and information, assembled for a purpose. c. SystemFunction - A automated process carried out by a system or system of systems. If the process is carried out only by a specific usage of a system, the systemusagecontext property points to the property which is typed by the system class in a composite structure model. d. SystemStateMachine - A state transition model which represents the behaviour of a system. MODAF-M7-022 Version

147 e. SystemStateMachineOwner - An item whose behaviour may be represented by a <<SystemStateMachine>> SV-10c Product Description Product Definition 407. The Systems Event-Trace Description provides a time-ordered examination of the system data elements exchanged between participating systems (external and internal), system functions, or human roles as a result of a particular scenario. Each event-trace diagram will have an accompanying description that defines the particular scenario or situation. SV-10c in the System Viewpoint may reflect system-specific aspects or refinements of critical sequences of events described in the Operational Viewpoint Product Purpose 408. SV-10c Products are valuable for moving to the next level of detail from the initial systems design, to help define a sequence of functions and system data interfaces, and to ensure that each participating system, system function, or human role has the necessary information it needs, at the right time, in order to perform its assigned functionality Detailed Product Description 409. SV-10c allows the tracing of actions in a scenario or critical sequence of events. With time proceeding from the top of the diagram to the bottom, a specific diagram lays out the sequence of system data exchanges that occur between systems (external and internal), system functions, or human role for a given scenario. Different scenarios will be depicted by separate diagrams. SV-10c can be used by itself or in conjunction with a SV-10b to describe dynamic behaviour of system processes or system function threads Figure 7-39 provides an example SV-10c product. The items across the top of the diagram represent systems located at nodes. Though SV-10c lifelines may also represent system functions or human roles that take action based on certain types of events. Each system, function, or human role has a lifeline associated with it that runs vertically. Specific points in time can be labelled on the lifelines, running down the left- hand side of the diagram. An event may occur as a result of an action. An event in a sequence diagram implies the action that produced it. Labels indicating timing constraints or providing event descriptions can be shown in the margin or near the transitions of the event(s) that they label. One-way arrows between the lifelines represent events, and the points at which they intersect the lifelines represent the times at which the system/function/role becomes aware of the events. The direction of the events represents the flow of control from one system/function/role to another based on the event. Each diagram may represent systems (external and internal) or system functions, but not both in the same diagram. Human roles may also be used in the diagram along with either systems or system functions in order to describe the humans interfaces to the systems or system functions. MODAF-M7-022 Version

148 <<Node>> :UAV Control <<Node>> :Land Component Command <<System>> :UAV <<System>> :ISTAR Analysis Suite <<System>> :Stills Camera <<System>> :IR Camera <<System>> :Video Camera <<System>> :Image Processing System <<System>> :Online Video Library <<System>> :Viewing System Image Submitted Notification IR Image Submitted Notification VT Clip Submitted Notification Figure 7-39: Systems Event-Trace Description (SV-10c) Template SV-10c UML Representation 411. UML sequence diagrams may be used to model SV-10c. Each diagram may represent systems (external and internal) or system functions, but not both in the same diagram. The example shown in Figure 7-39 shows how UML may be used. MODAF-M7-022 Version

149 SV-10c MODAF Meta Model Support BasicInteractions (from UML::Interactions) Interaction SystemInteractionSpecification (from MODAF::Systems) {redefines interaction} Lifeline { redefines lifeline} SystemLifeLine (from MODAF::Systems) {redefines represents } ConnectableElement (from UML::CompositeStructures::InternalStructures) SystemLifeLineItem (from MODAF::Systems) RoleInOrganisation (from MODAF::Operational) {aggregation = composite} SystemPort (from MODAF::Systems) SystemAssemblyUsage (from MODAF::Systems) {aggregation = composite} Figure 7-40: MODAF Meta Model Excerpt for SV-10c 412. For OV-6c and SV-10c, the complete use of stereotyping has not been deemed necessary - UML sequence (interaction) diagrams are ideal for representing these products. However, to constrain the use, and enable a distinction between OV-6c and SV-10c interaction models, the Interaction and Lifeline metaclasses are stereotyped The model elements used in SV-10c are: a. RoleInOrganisation - Defines a role in an organisation which is fulfilled by a post or by a sub-ordinate organisation. The role may or may not be fulfilled (i.e. roleprovider is null) - e.g. it may be a vacant post b. SystemAssemblyUsage - Used to link a parent system to its sub-systems. Only <<SystemAssemblyUsage>> may be used to represent a system-subsystem relationship. c. SystemInteractionSpecification - A specification of the interactions between aspects of a systems architecture (e.g. system usages, system ports, roles, etc.). d. SystemLifeLine - A lifeline that represents an aspect of a systems architecture which interacts with other items in the systems architecture. MODAF-M7-022 Version

150 e. SystemLifeLineItem - An item that may be represented as a lifeline in a SystemInteractionSpecification. f. SystemPort - An interface (logical or physical) provided by a <<System>>. A <<SystemPort>> may implement a <<PortType>>, though there is no requirement for SystemPorts to be typed. MODAF-M7-022 Version

151 7.11 Physical Schema (SV-11) SV-11 Product Description Product Definition 414. The Physical Schema Product is one of the Architectural Products closest to actual system design in the Framework. The Product defines the structure of the various kinds of system data that are utilised by the systems in the Architecture Product Purpose 415. The Product serves several purposes, including a. providing as much detail as possible on the system data elements exchanged between systems, thus reducing the risk of interoperability errors b. providing system data structures for use in the system design process, if necessary Detailed Product Description 416. SV-11 is an implementation-oriented Data Model that is used in the System Viewpoint to describe how the information requirements represented in Logical Data Model (OV-7) are actually implemented. Entities represent a. system data flows in SV-4, b. system data elements specified in SV-6, c. triggering events in SV-10b, and/or d. events in SV-10c There will be a mapping from a given OV-7 to SV-11 if both models are used. The form of SV-11 can vary greatly, as shown in Figure For some purposes, an Entity relationship style diagram of the physical database design will suffice. References to message format standards (which identify message types and options to be used) may suffice for message oriented implementations. Descriptions of file formats may be used when file passing is the mode used to exchange information. A Data Definition Language (DDL) (e.g., Structured Query Language [SQL]) may also be used in the cases where shared databases are used to integrate systems. Interoperating systems may use a variety of techniques to exchange system data and have several distinct partitions in their SV-11 with each partition using a different form. Standards associated with entities are also documented in this Product. MODAF-M7-022 Version

152 Figure 7-41: Physical Schema (SV-11) Representation Options SV-11 UML Representation 418. SV-11 may be modelled in UML using a class diagram (with appropriate M 3 defined stereotypes) - see Figure To maintain compatibility with more mainstream data modelling approaches (e.g. E-R modelling), only UML classes, associations and properties are allowed in SV-11 << PhysicalDataModel >> ImageManagementSystem << entity >> Image -imagesizeinbytes:longint -imagename:string[20] -description:varstring -capturedatetime:datetime -location:gpscoordinates + creator + owner << entity >> Person -name:string[40] -rank:string[20] + user + usedimage << entity >> ImageUsage -retrievaldate:datetime -reasonforretrieval:varstring Figure 7-42: Class Diagram for Physical Schema (SV-11) MODAF-M7-022 Version

153 SV-11 MODAF Meta Model Support PhysicalDataModel (from MODAF::Systems) Generalization (from UML::Classes::Kernel) DataModel Package (from UML::Classes::Kernel) + entities * {redefines ownedmember} SubtypeRelationship + subtype {redefines specific} + supertype Entity Class (from UML::Classes::Kernel) {redefines general} { subsets ownedattribute} EntityRelationship {subsets ownedend} {subsets memberend} Attribute Property (from UML::Classes::Kernel) 2 Association (from UML::Classes::Kernel) Figure 7-43: MODAF Meta Model Excerpt for SV Data models in MODAF have classes, relationships and attributes, effectively giving Entity-Relationship capability. Subtyping (generalisation / specialisation) is also permitted The model elements used in SV-11 are: a. Attribute - A property of an entity. b. DataModel - A structural specification of data, showing classifications of data elements and relationships between them. c. Entity - A definition (type) of an item of interest. d. EntityRelationship - Asserts that there is a relationship between two entities. MODAF-M7-022 Version

154 e. PhysicalDataModel - A <<PhysicalDataModel>> is an implementable specification of a data structure. A <<PhysicalDataModel>> realises a <<LogicalDataModel>>, taking into account implementation restrictions and performance issues whilst still enforcing the constraints, relationships and typing of the logical model. f. SubtypeRelationship - Asserts that one entity (subtype) is a specialization of the other (supertype). MODAF-M7-022 Version

155 8 Technical View Products 421. TVs are common to both MODAF and DoDAF; TV-1 however, has been customised to provide for MOD requirements TVs provide the technical systems-implementation standards upon which engineering specifications are based, common building blocks are established, and Product lines are developed. There are two TV Products: a. Technical Standards Profile (TV-1) b. Technical Standards Forecast (TV-2) 423. A description for each of these Views is included below. MODAF-M7-022 Version

156 8.1 Technical Standards Profile (TV-1) TV-1 Product Description Product Definition 424. The Technical Standards Profile (TV-1) collates the various systems, Standards and rules that implement and constrain the choices that can be made in the design and implementation of an Architectural Framework Product Purpose 425. The TV-1 View delineates the systems, Standards and rules that apply to architectural implementations Detailed Product Description 426. The TV-1 View, an example of which is shown in Figure 8-1 consists of the set of systems, Standards, and rules that govern systems implementation and operation of that Architecture. The technical standards govern what hardware and software may be implemented and on what system. The standards that are cited may be international such as ISO standards, national standards or organisational specific standards such as a CONOP, a CONEMP or a CONUSE. Any Standards cited in TV-1 View shall, where appropriate, be in accordance with the trend towards open Architectures i.e. standards which encourage stove-piped systems will not be used. Identified standards may require tailoring to fulfil the needs of the system being represented within the Architectural Framework; this tailoring is called creating a Standards Profile. Standards Profiles for a particular Architecture must maintain full compatibility with the root standards they have been derived from. In addition, the TV-1 View may state a particular method of implementation for a Standard, as compliance with a Standard does not ensure interoperability. The Standards cited are referenced as relationships to the systems, system functions, system data, hardware/software items or communication protocols in SV-1, SV-2, SV-4, SV-6, OV-7, and SV-11 Products, where applicable. That is, each standard listed in the profile will be associated with the SV elements that implement or use the standard (e.g., SV-1, SV-2, SV-4, SV-6, OV-7 and SV-11 element standards, where applicable). Service Area Service System Elements Standard / Policy Transport Services TCP/IP BOWMAN IP v6 Data transfer Data compression algorithms CRYPTO JSP XXX ISO XXX Operating System Microsoft Windows JOP JSP XXX ISO XXX Deployment Physical Activity HQ Equipment SOP A TV-1 UML Representation Figure 8-1: An example of the TV-1 View 427. There is no specific UML diagram that is applicable to the TV-1 View. MODAF-M7-022 Version

157 8.1.3 TV-1 and TV-2 MODAF Meta Model Support Standard -identifier:string -ratificationdate:timeexpression -withdrawaldate:timeexpression -publishedwebsite:string -publisher:string -name:string -version:string Constraint (from UML::Classes::Kernel) Figure 8-2: MODAF Meta Model Excerpt for TV-1 and TV Only one stereotype is required for TV-1 - <<Standard>> - which can be applied throughout the architecture and listed in a TV-1 product The model elements used in TV-1 are: a. Standard - A ratified and peer-reviewed specification that is used to guide or constrain the architecture. A <<Standard>> may be applied to any element in the architecture via the constraineditem property of UML::Constraint. MODAF-M7-022 Version

158 8.2 Technical Standards Forecast (TV-2) TV-2 Product Description Product Definition 430. The Technical Standards Forecast contains expected changes in technology-related standards and conventions, which are documented in the TV-1 Product. The forecast for evolutionary changes in the standards need to be correlated against the time periods mentioned in the SV-8 and SV-9 Products Product Purpose 431. One of the prime purposes of this Product is to identify critical technology standards, their fragility, and the impact of these standards on the future development and maintainability of the Architecture and its constituent elements Detailed Product Description 432. TV-2 lists emerging or evolving technology standards relevant to the systems covered by the Architecture. It contains predictions about the availability of emerging standards, and relates these predictions to the System Viewpoint elements and the time periods that are listed in the SV-8 and SV The specific time periods selected (e.g., 6-month, 12-month, intervals) and the standards being tracked will be coordinated with Architecture transition plans (see SV-8). That is, insertion of new technological capabilities and upgrading of existing systems may depend on, or be driven by, the availability of new standards and Products incorporating those standards. The forecast specifies potential standards and thus impacts current Architectures and influences the development of transition and objective (i.e., target) Architectures. The forecast will be tailored to focus on standards areas that are related to the purpose for which a given Architecture is being described and should identify potential standards affecting that Architecture. If interface standards are an integral part of the technologies important to the evolution of a given Architecture, then it may be convenient to combine TV-2 with SV-9. For other projects, it may be convenient to combine all the standards information into one document, combining TV-2 with TV-1. A TV-2 example is shown in Figure 8-3. MODAF-M7-022 Version

159 TRM STANDARDS FORECASTS CATEGORY SHORT TERM MID TERM LONG TERM (1 year) (3 years) (5 years) Application Platform Data Interchange Document Interchange Security Marking DTD in CAPCO coordination (proposed IC standard) Mapping Geography DTD 2.0 accepted by GIS Consortium Commercial products that use the standard become available Geospatial XSD in coordination Open GIS Geospatial XSD accepted by Open GIS Communications Electronic Mail IETF RFC2060 Internet Mail Access Protocol (IMAP) accepted, replaces de facto standard World Wide Web Services IETF - Common Gateway Interface (CGI) 1.2 becomes proposed standard IETF Common Gateway Interface (CGI) 1.2 accepted, replaces CGI 1.1, the de facto standard IETF RFC 2818 HTTP Over TLS accepted, replaces RFC 2616 Communications Transport Services IETF Wireless Extensions to TLS becomes proposed standard IETF RFC 2002 IP Mobility Support - accepted IETF IPv4 Mobile IP Protocol becomes propose standard Security IETF - RFC 2246 The Transport Layer Security (TLS) Protocol Version1.0 accepted; replaces SSL Figure 8-3 Technical Standards Forecast (TV-2) 434. TV-2 delineates the standards that will potentially impact the relevant system elements (from SV-1, SV-2, SV-4, SV-6, and OV-7) and relates them to the time periods that are listed in the SV-8 and SV-9. A system s evolution, specified in SV-8, may be tied to a future standard listed in TV-2. A timed technology forecast from SV-9 is related to a TV-2 standards forecast in the following manner: a certain technology may be dependent on a TV-2 standard (i.e., a standard listed in TV-2 may not be adopted until a certain technology becomes available). This is how a prediction on the adoption of a future standard, as applicable to systems elements from SV-1, SV-2, SV-4, SV-6, and OV-7, may be related to standards listed in TV-1 through the SV-9. A template for TV-2 is not shown in this section. The same template (see Figure 8-1) shown in TV-1 may be used to describe TV TV-2 UML Representation 435. There is no specific UML diagram that is applicable to the TV-2 View. MODAF-M7-022 Version

160 8.2.3 TV-1 and TV-2 MODAF Meta Model Support Standard -identifier:string -ratificationdate:timeexpression -withdrawaldate:timeexpression -publishedwebsite:string -publisher:string -name:string -version:string Constraint (from UML::Classes::Kernel) Figure 8-4: MODAF Meta Model Excerpt for TV-1 and TV As with TV-1, only <<Standard>> is required for TV-2. The <<Standard>> may be applied throughout the architecture and listed in TV The model elements used in TV-2 are: a. Standard - A ratified and peer-reviewed specification that is used to guide or constrain the architecture. A <<Standard>> may be applied to any element in the architecture via the constraineditem property of UML::Constraint. MODAF-M7-022 Version

161 9 Acquisition View Products 438. Acquisition Views (AcVs) are unique to MODAF, implemented in addition to those in DoDAF. They have been introduced to describe programmatic details, including dependencies between projects and capability integration across the all the DLODs. These Views guide the acquisition and fielding processes. There are two AcV Products: a. SoS Acquisition Clusters (AcV-1) b. SoS Acquisition Programmes (AcV-2) 439. A description for each of these Views is included below. MODAF-M7-022 Version

162 9.1 SoS Acquisition Clusters (AcV-1) AcV-1 Product Description Product Definition 440. An System of Systems Acquisition Clusters (AcV-1) Product describes how acquisition projects are organisationally grouped in order to form coherent acquisition programmes Product Purpose 441. The System of Systems Acquisition Clusters View enables the user to define the best acquisition structure to support the multiple projects under analysis. The goal is to populate the hierarchy of acquisition clusters and programmes with projects that integrate together and / or are highly dependent upon each other, so as to improve the ability to manage this integration / dependency. As such, this View is primarily of interest to those who are responsible for programmes of acquisition projects Detailed Product Description 442. An AcV-1 System of Systems Acquisition Clusters Product provides a way of describing the organisational relationships between multiple acquisition projects, each of which are responsible for delivering individual systems. By definition, this View covers acquisition programmes consisting of multiple projects and will generally not be developed by those building Architectures for an individual project An AcV-1 Product is hierarchical in nature. Though there is no prescribed diagrammatic format for an AcV-1 Product, it is required that they are represented by a diagram or table that clearly shows: a. All of the acquisition projects delivering systems or SoS within the acquisition programme under consideration b. Other systems and systems of systems which may have a bearing on the Architecture c. How the systems will be best integrated into acquisition clusters d. How the acquisition clusters can be composed of other clusters (i.e. a hierarchy) 444. A given AcV-1 Product may change through time i.e. the clusters are likely to change as new systems are introduced into the acquisition programme. Hence, it is likely that any given acquisition programme may have more than one AcV-1 Product, each showing how the acquisition clusters are arranged for relevant periods of time Figure 9-1 shows an example AcV-1 Product for the acquisition organisation of the Defence Procurement Agency (DPA). This shows how current acquisition projects are organised into acquisition programmes (also known as clusters) of related capabilities under the leadership of an appropriate director or deputy director Figure 9-2 shows an example AcV-1 Product for a cluster of acquisition projects that relate to a part of the overall Intelligence, Surveillance, Target Acquisition and Reconnaissance (ISTAR) capability. This View can be used to understand the dependencies and relationships between elements of the acquisition cluster and hence how best to develop the organisational relationships that will manage the dependencies between projects and the integration of the broader ISTAR capability. MODAF-M7-022 Version

163 Figure 9-1: Example DPA Acquisition Clusters Beyond Line of Sight ISTAR & Effects Information Surveillance Imagery Watchkeeper Canberra Electronic Warfare Soothsayer Effects Phoenix Special Projects HUMINT Equipment Jaguar Nimrod R ELINT Strike Tomahawk Missile Artillery Land Comms Bowman Cormorant Comms Sat Comms Skynet 5 Specialist Comms Specialist Comms (SPCICR) Figure 9-2: Example AcV-1 for Hypothetical ISTAR Cluster AcV-1 UML Representation 447. AcV-1 Views lend themselves well to UML representation. Projects are stereotyped from instances. The systems themselves are stereotyped classes and shown traced to the project that procures them. MODAF-M7-022 Version