1. DoD Architecture Framework V 1.0 Dr. Fatma Dandashi The MITRE Corporation April 8, 2003 Operational Systems Technical 2. Context and Relationship To This Audience Manufacturing (Hardware Parts) AP233 Systems Engineering Processes and Modeling Standards Mission Needs/ Information Interoperability Requirements Software Parts/ Information UML/XMI Industry Standards Systems of Systems (Software Intensive) Operational Systems Technical 3. Architecture Defined Architecture "An architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.” IEEE STD 1471-2000 Architecture Description Graphical, tabular or textual representations of the architecture Architecture Discipline A discipline for developing and analyzing an architecture in terms of its processes, components, and their relationships and rules. Architecture = Structure of Components Relationships Principles & Guidelines + + 4. Why Architecture? Architecture is about structure and relationships Making things fit together and work together well Architecture is about Categories to identify and clarify, facilitate reuse, eliminate redundant efforts Economy Demands Things Fit Together And Work Well With Minimal Investment, Taking Advantage Of Reuse, And - Eliminating Unnecessary Redundant Efforts 5. Parallel Revolutions Information Revolution Widespread E-Commerce Wideband Internet to Homes Apple Personal Computer Internet Goes ‘Public’ Low Cost Cell Phone Service Windows 95 Windows 98 Windows 2000/XP U.S. Dept of Defense PPBS Process Changes? Capabilities-Based Acquisition? … ??? Goldwater-Nichols Act DARPA Focuses on Infotech Strategic Defense Initiative Joint Force in Gulf War JV2010 – Integrated Defense Strategy Joint Staff Begins Architecture Focus JFCOM Formed C4ISR AF JV2020 Terrorism Strikes US (9/11) Dept of Homeland Security DOD 5000 Acquisition Reformed DoDAF Version 1 Required DAB Reviews JMA CJSCI 3170 (Draft) Clinger-Cohen Act Digital Wireless Phones Introduced End of the Soviet Empire ‘ Fall of the Wall’ 1985 86 87 88 89 90 91 92 93 94 95 96 97 98 99 00 01 02 03 04 … 1985 86 87 88 89 90 91 92 93 94 95 96 97 98 99 00 01 02 03 04 … 6. Need for Integrated Architecture Descriptive Products Agency or battlefield must work together Must integrate many business processes, data flows, much infrastructure Need a description and structure of how to work together Need integrated set of products to capture relationships for understanding and analysis Need to assess dependencies and impacts Systems of Systems Agency Cross Agency - Must have architecture, To document/ analyze interfaces - Assess impacts and dependencies - How agency achieves mission, - what are priorities - Use architecture for how sharing, intertwined processes, communications occur - Assess impacts and dependencies - Use reference models to identify similar functions, efforts, potential joint work; Use architecture for how sharing, intertwined processes, communications occur 7. Policy and Guidance on Architecture – Mandate for Architectures Information Technology Management Reform Act (ITMRA)/Clinger-Cohen Act. (1996) Mandates that Chief Information Officers of Executive Agencies are responsible for “ developing, maintaining, and facilitating the implementation of a sound and integrated information technology architecture for the executive agency “. Executive Order 13011: Federal Information Technology (1996). Executive Agencies shall appoint a Chief Information Officer and “shall refocus information technology management to support directly their strategic missions, implement an investment review process that drives budget formulation and execution for information systems, and rethink and restructure the way they perform their functions before investing in information technology to support that work.” Chief Information Officer of the Department of Defense. Review and provide recommendations to the Secretary of Defense on Department of Defense budget requests for information technology and national security systems. 8. DoD Policy on Using Architectures DoDD 4630.5, Interoperability and Supportability of Information Technology (IT) and National Security Systems, January 11, 2002 DoDI 4630.8, Interoperability and Supportability of Information Technology (IT) and National Security Systems, May 2, 2002 DoDD 8000.1, Management of DoD Information Resources and Information Technology, February 27, 2002 DoDD 8100.01, Global Information Grid Overarching Policy, September 19, 2002 DoDI 5000.2, Operations of the Defense Acquisition System, draft October 2002 CJCSI 3170.01C, Joint Capabilities Integration and Development System, draft 2003 (Replacement for Requirements Generations System) Recent DoD policy highlights use of architectures for: Understanding the DoD as an enterprise Identification of operational requirements Rationalization of IT investment decisions Improvements to interoperability among various systems 9. Policy Enabled by Common Approach for Developing Architectures DoD Architecture Framework (DODAF) Common approach for developing an architecture description Core Architecture Data Model (CADM) Common data model for architecture data DoD Architecture Repository System (DARS) Common repository for storing and retrieving architecture data DoD Guidance on Developing Architectures 10. Increased Emphasis on Meta-Data Standardization Each DODAF product description Information Element Definition Table CADM Support Core Architecture Data Model (CADM) Build Architectures IAW CADM DoD Architecture Data Repository (DARS) CADM compliant data repository Hosts accredited DoD architecture information 11. DODAF Core Data Elements Facilities, Locations, Units, and Platforms DODAF Product data Elements, CADM Model, & Basis for DARS Schema 12. Core Architecture Data Model (CADM) * CADM is a database design for architecture data * Products convey relationship between architecture data elements CADM Schema of Product field contents Activity Model Systems Interface Description DODAF Product DODAF Arch Data Element System Functions Business (Organization) Nodes Systems (Location) Nodes Business Activities Systems Standards Performance Data Information Technologies 13. DARS Architecture TCP/IP Port 1521 Tape back-up Oracle 9.2 Database Server Tape back-up Oracle Internet Application Server R2 w/ Oracle Portal FIREWALL Desktop with Internet Explorer Modeling Tools (System Architect) Desktop with Internet Explorer Modeling Tools (SLATE) Desktop with Internet Explorer Modeling Tools (ROSE) HTTP Port 443 Various Users, Various Modeling Tools Architecture Data, CADM Schema 14. Benefits of Architecture Meta-Data Standardization Reuse of data Consistency that facilitates integration Flexibility in partitioning of data from different points of view Ability to use automated architecture and modeling tools interchangeably Better support for analysis and decision-making Increased emphasis on development of integrated architectures De-emphasis of an architecture product-by-product approach 15. Developing a DoD Enterprise Architecture Distributed Architecture Development in accordance with Results in ... Assures that architectures are integratable across the community Establishes threads that tie the architecture views together Provides the basis for an audit trail that relates systems to measures of mission effectiveness Joint Mission Areas NEO JTF Targeting/BDA AF Task Force Integratable architectures that exploit opportunities for integrated, interoperable, and cost-effective capabilities Joint Mission Areas AF Task Force Targeting & BDA Tactical Internet Military Service NEO JTF CC NIMA Global Information Grid IC National Theater CJTF Tactical Tactical Internet Global Information Grid IC Military Service NIMA Operational Systems Technical Framework DARS - Repository CADM – Data Model CC 16. DoD Architecture Framework The Department of Defense (DoD) Architecture Framework (DODAF) Defines a standard approach for describing, presenting, and integrating DoD architectures The principal objective of the Framework is to Ensure that architecture descriptions can be compared and related across organizational boundaries, including Joint and multi-national boundaries 17. DoD Architecture Framework DODAF is partitioned into Volume I: Definitions, guidelines, and background material Designed for managers Volume II: Descriptions of products Designed for architects and engineers Deskbook: Supplementary material (How to) guidance on architecture development and use Designed for engineers Expected Release – June 2003 Available on the Web http://flrc.mitre.org/dodfw/ 18. Basic Principles - An Integrated Architecture with Three Views Systems Information Flow Operational Nodes Data Flow Communications Prescribes Technical Standards Technical Standards View Standards Services Activities/ Tasks Specific Capabilities Required to Satisfy Information Exchanges Technical Criteria Governing Interoperable Implementation/ Procurement of the Selected System Capabilities Basic Technology Supportability New Technical Capabilities What Needs to Be Done Who Does It Information Exchanges Required to Get It Done Identifies Participant Relationships And Information Needs Operational View Relates Systems Capabilities to Operational Requirements Systems View Operational Capability Requirements Service Areas Systems that Support the Activities and Information Exchanges X Y X Z X Y Y 19. Basic Principles - Graphic, Textual, and Tabular Products Operational Concept Description (OV-1) Activity Model (OV-5) Information Exchange Matrix (OV-3) System Functionality Description (SV-4) Systems Data Exchange Matrix (SV-6) Operational Activity Sequence and Timing Description (OV-6 a/b/c) Systems Communications Description (SV-2) System - System Matrix (SV-3) Systems Technology Forecast (SV-9) Standards Technology Forecast (SV-9) Technical Architecture Profile (TV-1) Systems Performance Parameters Matrix (SV-7) Logical Data Model (OV-7) Systems Functionality Sequence and Timing Description (SV-10 a/b/c) Systems Evolution Description (SV-8) Physical Schema SV-11 Operational Systems Technical Node Connectivity Description (OV-2) X Y X Z X Y Y Systems Interface Description (SV-1) Activity to System Function (SV-5) Organizational Relationships Chart (OV-4) -------------------------------- • ..... • ..... • ..... A B C T1 T2 T3 NODES TIME A B C T1 T2 T3 NODES TIME 20. Systems Architecture Viewpoints* Relationship to DODAF ISO standard ISO/IEC 10746-1: Reference Model – Open Distributed Processing (RM-ODP) Technology standards and properties attached to systems and subsystems Matrices The system and its environment that focuses on the choice of technology in that system. Technology Viewpoint Sequence and Collaboration diagrams, Class Diagrams, OO DBs Data Models, Physical Data Schema Relational Databases Data managed by the system Information Viewpoint Component and Deployment Diagrams Physical Distribution Mechanisms to support distribution of functionality Engineering Viewpoint Statechart & Activity Diagrams, Sequence Diagrams Statecharts Threads of control, which carry out the computation elements Classes, Class Diagrams, and related Diagrams Data Flow Diagrams Logical decomposition of the system as a set of class objects/subsystems Computational Viewpoint Use Cases, Use Case Diagrams and related Diagrams IDEF0 Diagrams Business activities supported by the system Enterprise Viewpoint DoD Framework UML Products DoD Framework products Expresses RM-ODP View Points 21. Evolution of the Framework & Timeline Road Map DoD Architecture Coordination Council C4ISR Architecture Framework Version 2.0 June 1996 Dec 1997 C4ISR ITF Integrated Architectures Panel Prior Community Experiences DoD Architecture Framework Version V 1.0 2002 OSD Mandate Feb 1998 Lead by: Directorate for Architectures and Integration OASD(C3I) Architecture Framework Working Group 2003 C4ISR Architecture Working Group C4ISR Architecture Framework Version 1.0 22. DODAF Architecture Products Technical Standards Forecast TV-2 Technical Technical Standards Profile TV-1 Technical Physical Schema SV-11 Systems Systems Functionality Sequence and Timing Descriptions SV-10a, b, c Systems Systems Technology Forecast SV-9 Systems Systems Evolution Description SV-8 Systems Systems Performance Parameters Matrix SV-7 Systems Systems Data Exchange Matrix SV-6 Systems Operational Activity to Systems Function Traceability Matrix SV-5 Systems Systems Functionality Description SV-4 Systems Systems-Systems Matrix SV-3 Systems Systems Communications Description SV-2 Systems Systems Interface Description SV-1 Systems Logical Data Model OV-7 Operational Operational Activity Sequence and Timing Descriptions OV-6a, b, c Operational Operational Activity Model OV-5 Operational Organizational Relationships Chart OV-4 Operational Operational Information Exchange Matrix OV-3 Operational Operational Node Connectivity Description OV-2 Operational High-Level Operational Concept Graphic OV-1 Operational Integrated Dictionary AV-2 All Views Overview and Summary Information AV-1 All Views Framework Product Name Framework Product Applicable View 23. Some DODAF Architecture Products (Business Process) Operational Activity Model Analyze Market Information Reports Outputs (Business Organization) Operational Node Connectivity Description HQ Field Office DP Center Phone e-mail Phone e-mail T3 Line, Satellite Phone E-mail Inputs Systems Interface Description System Node Interface System System Node System System System Node System Technical Standards Profile Operational Information Exchange Matrix Producing Node Producing Activity Receiving Node Receiving Activity Information Needline Information Exchanged Also Includes: Triggering Event Description, ‘Properties’, Performance, Security Service Area Service Standard Applications Software Data Document XML 1.0 Interchange Interchange (Business Concept) High-Level Operational Concept Graphic Importer/Exporter/ Broker SAFE, LEGAL, OPEN TRADE Carriers Goods Overview and Summary Integrated Dictionary Dictionary allows capture of Arch definitions, relationships, attributes, rules Activity 1 Activity 2 Activity 3 Activity 4 Activity 5 Activity Hierarchy 24. Operational View Captures Critical Mission Relationships and Information Exchanges Node A Node B Activity 1 Activity 2 Node C Activity 3 Activity 2 Activity 3 Information Description Name/Identifier Definition Media Size Units Information Exchange Attributes Frequency, Timeliness, Throughput Security Interoperability Requirements Information Source Information Destination Information Exchange 1 High-Level Operational Concept Description Operational Node Connectivity Description Operational Information Exchange Matrix High-level graphical description of the operational concept of interest Operational nodes, activities performed at each node, node-to-node relationships, and information needlines Summary of Information exchanged between nodes with attributes, such as security, timeliness To External Node From External Node Operational Activity Model Operational activities, information inputs and outputs, conditions Operational Process 1 Outputs Inputs Operational Process 2 Information Information Inputs 25. Systems View Captures Systems, Functions Performed, Data, and Network Layout Systems Functionality Description SV-4 Can include systems, H/W & S/W Items, Interfaces (conceptual), System Functions Can include systems, communications nodes, networks, paths, Links forming path, protocols supported Includes data sources and sinks, repositories, data flows between system functions Describes planned systems evolution over time Data Flow Among System Functions System Function 1 System Function 2 External Source Data Flow 1 Data Flow 2 Data Repository System Nodes, Systems, Links Systems Interface Description SV-1 Communication Pathways and Networks, Configuration Detail Station Base System A System B System C Systems Communications Description SV-2 Capability Evolution and Migration Cap 1 Cap 2 Cap 3 Cap 4 V 1.0 V2.0 Systems Evolution Description SV-8 26. Technical Architecture Profile (TV-1) Dictionary Content Reference Model Name Service Area Name Service Name Standard Name System Name System Hardware/ Software Item Name Communications System Name Communications Link Name Relationships in Dictionary Orange indicates Technical Architecture Elements Green indicates system product Data Element Reference Model Service Area Service Standard System System Hardware/Software Item Communications System Communications Link Systems Data Exchange System Function Physical Schema Model Systems Data Exchange Physical Schema Model System Function 27. Matrix of Products According to Use Requirements generation process Products needed in Requirements Analysis 28. Matrix of Products According to Use Purpose Provide guidance on which architecture products are applicable to various uses of architecture Emphasis and expectation Architecture data underlying the products will be used to support the DoD core processes List of uses is not comprehensive but rather a summary of uses supporting DoD core processes Increased emphasis on development of integrated architectures and de-emphasis of an architecture product-by-product approach Requires tighter integration between staffs, operational, and acquisition communities 29. DODAF Products and UML Representation Class Diagrams Logical Data Model OV-7 Operational UML Sequence Diagrams Operational Event-Trace Description OV-6c Operational UML Statechart Diagrams Operational State Transition Description OV-6b Operational None: Produced from pre- and post- conditions on OV-5 use cases, or derived from StateChart Diagrams supporting OV-5 and OV-7 diagram and element adornments Operational Rules Model OV-6a Operational Use case Diagrams + Activity Diagrams (to show threads) + Sequence Diagrams (OV-6c) and StateChart Diagrams (OV-6b) Operational Activity Model OV-5 Operational Class Diagrams, maps to OV-5 use case actors Organizational Relationships Chart OV-4 Operational None: Produced from Collaboration or Sequence Diagram messages (OV-2 collaboration messages) + additional adornments (e.g., IA attribute) Operational Information Exchange Matrix OV-3 Operational Collaboration Diagrams for operational/ organizational nodes Operational Node Connectivity Description OV-2 Operational None: but may be produced via Use Case Diagrams, one for each use or mission Produced from domain knowledge High-Level Operational Concept Graphic OV-1 Operational None: Produced from diagram and element annotations Integrated Dictionary AV-2 All Views None: Produced from domain knowledge, diagram and element annotations Overview and Summary Information AV-1 All Views UML Diagram Framework Product Name Framework Product Applicable View 30. DODAF Products and UML Representation None: Produced from SV-1, SV-2, & SV-4 diagram and element annotations. information may be derived from system sequence diagrams Systems Data Exchange Matrix SV-6 Systems None: Produced from OV-5 & SV-4 diagram and element annotations. information may be derived from operational sequence diagrams that are refined into system sequence diagrams Operational Activity to Systems Function Traceability Matrix SV-5 Systems Use Case Diagrams + Class Diagrams (with operations) + Collaboration Diagrams (to show data flows or exchanges) Systems Functionality Description SV-4 Systems None: Produced from SV-1/2 diagram and element adornments Systems-Systems Matrix SV-3 Systems Deployment Diagrams + Component Diagrams for Intra-nodal and Intra-system version of SV-2 Systems Communications Description SV-2 Systems Deployment Diagrams + Component Diagrams for Intra-nodal and Intra-system version of SV-1 Systems Interface Description SV-1 Systems UML Diagram Framework Product Name Framework Product Applicable View 31. DODAF Products and UML Representation Class Diagrams Physical Schema SV-11 Systems UML Sequence Diagrams Systems Event-Trace Description SV-10c Systems UML Statechart Diagrams Systems State Transition Description SV-10b Systems None: Produced from SV-4, SV-11 diagram and element annotations and constraints, or derived from StateChart Diagrams supporting SV-4 Systems Rules Model SV-10a Systems None: Domain knowledge, Technology Knowledge, and Framework Systems View Products Systems Technology Forecast SV-9 Systems None: Domain Knowledge, and Framework Systems View Products Systems Evolution Description SV-8 Systems None: Produced from SV-1, SV-2, & SV-4 diagram and element annotations Systems Performance Parameters Matrix SV-7 Systems UML Diagram Framework Product Name Framework Product Applicable View 32. DODAF Products and UML Representation None: Produced from system elements and applicable Technical standards Technical Standards Forecast TV-2 Technical None: Produced from system elements and applicable Technical standards Technical Standards Profile TV-1 Technical UML Diagram Framework Product Name Framework Product Applicable View 33. Other Agencies Building The Same Sets Of Comparable Products And Data Elements US Customs Service Architecture Products GSA Enterprise Architecture Framework Treasury Enterprise Architecture Framework Architecture Framework V1.0 IC Architecture Products Federal Enterprise Architecture Framework Homeland Security Architecture Products DoD Architecture Framework OPERATIONAL INFORMATION ELEMENT DESCRIPTION MEDIA SIZE UNITS NAME/IDENTIFIER DEFINITION DIGITAL, VOICE, TEXT, IMAGE, ETC. RANGE LIMITS FEET, LITERS, INCHES, ETC. OPERATIONAL ELEMENT & ACTIVITY OPERATIONAL ELEMENT & ACTIVITY IDENTIFIER OF PRODUCING OE PRODUCING ACTIVITY IDENTIFIER OF CONSUMING OE CONSUMING ACTIVITY INFORMATION SOURCE INFORMATION SOURCE INFORMATION DESTINATION INFORMATION DESTINATION FREQUENCY, TIMELINESS, THROUGHPUT SECURITY INTEROPER- ABILITY REQUIREMENTS INFORMATION EXCHANGE ATTRIBUTES INFORMATION EXCHANGE ATTRIBUTES INFORMATION DESCRIPTION INFORMATION DESCRIPTION Operational Information Exchange Matrix NODE A System Interface Description NODE B NODE C SYSTEM 2 SYSTEM 1 EXTERNAL CONNECTION SYSTEM 1 COMMS Interface COMMS Interface COMMS Interface One-way SATCOM Interface SYSTEM 2 SYSTEM 3 SYSTEM 1 SYSTEM 4 Technical Architecture Profile Activity 3 Node A Node B Activity 1 Activity 2 Node C Activity 2 Activity 3 • Information Description • Name/Identifier • Definition • Media • Size • Units • Information Exchange Attributes • Frequency, Timeliness, Throughput • Security • Interoperability Requirements • Information Source • Information Destination Information Exchange 1 Operational Node Connectivity Description Activity Model SERVICE AREA SERVICE STANDARD Support Applications Web Applications Internet Explorer Version 4.X or better Netscape Version 3.X or better Data Management Business Data Standards Data Universal Numbering System (DUNS) ZIP Code Directory Congressional District Identifier ISO 3166: ISO 3166-1 (1Ocober 1997) and ISO 3166-2 (15 December 1998) (Codes for the Representation of Names of Countries and Their Subdivisions) U.S. State Codes and Territory Codes Catalogue for Federal Domestic Assistance Program Electronic Grants Data Elements Data Interchange Document Interchange XML 1.0, W3C Recommendation, 10 February 1998, Rec-xml-19980210 (Extensible Markup Language) HTML 4.0 Specification, W3C Recommendation revised 24-apr-1998, Rec-html40- 19980424 (Hypertext Markup Language) ANSI ASC X12 (Electronic Data Interchange) Communications World Wide Web Services IETF RFC-2616 Hypertext Transfer Protocol – HTTP/1.1, June 1999 Electronic Mail IETF Standard 10/RFC-821/RFC-1869/RFC-1870 Simple Mail Transfer Protocol (SMTP) Service Extensions, November 1995 IETF Standard 11/RFC-822/RFC-1049 Standard for the Format of ARPA Internet Text Messages, 13 August 1982 IETF RFCs 2045-2049 Multipurpose Internet Mail Extensions (MIME), November 1996 34. Other Countries Building Similar Sets Of Comparable Products And Data Elements NATO’s Architecture Framework Taiwan’s Architecture Australia’s Architecture Framework Sweden’s Architecture Framework UK’s Architecture Framework 35. DODAF V 1.0 - Summary DoD Issuances provide “teeth” for the architecture process DoD Architecture Framework Emphasis on developing and using architectures to support Department’s major processes Acquisition (5000), Requirements (3170), Budget processes Interoperability Model-Driven analysis based on a data-centric approach 36. Contact Information Owner of the Architecture Framework: OASD(C3I)/DoD CIO, The Directorate for Architectures and Integration Government Lead: Truman Parmele 703-607-0502 Support for the Framework: Fatma Dandashi - Mitre 703-883-7914 Huei-Wan Ang - Mitre 703-883-6701 Patsy McGrady - ACS-Defense 757-229-7887 Available on the Web http://flrc.mitre.org/dodfw/ 37. Backup Slides 38. Operational Node Connectivity Description (OV-2) : Node A : Node B : Node C : External Source : External Destination Performs: Activity 1 Activity 2 Performs: Activity 3 Performs: Activity 2 Activity 3 Needline 2 2: Information Type Y Needline 1 3: Information Type X Needline 3 4: Information Type W Needline 4 1: Information Type Z 39. Operational Information Exchange Matrix (OV-3) 40. Organizational Relationships Chart (OV-4) Third Level Organization D Third Level Organization C Second Level Organization A Commands Commands Working Group Coordinates Second Level Organization B Top Level Organization Commands Coordinates Commands 41. Operational Activity Model (OV-5) Node C Node A Node B Activity 2 External Activity 1 Activity 1 Flow1 Flow 2 External Activity 2 Node D Activity 3 Flow 3 Flow 4 Conducts Conducts Conducts Conducts Conducts 42. Operational Activity Model (OV-5) 43. The Operational State Transition Description (OV-6b) State 2 State 1 Event[ Guard Condition ] / Action 44. The Operational Event-Trace Description (OV-6c) : Op Node A : Op Node B : Op Node C Message 1 Time 1 Message 2 Time 2 {formula relating Time 1 to Time 2} Message 3 Time n Time 3 Message 4 Message 5 Time 4 {formula relating Time 3 to Time 4} Message 6 Message 7 Message 8 45. Logical Data Model (OV-7) Entity 2 Name Attribute 1 Name Attribute 2 Name ... Entity 3 Name Attribute 1 Name Attribute 2 Name ... Entity 1 Name Attribute 1 Name Attribute 2 Name ... Relationship Name Entity 4 Name Attribute 1 Name Attribute 2 Name ... 46. Systems Interface Description (SV-1 & 2) Interface 2 Node A System 1 System 5 Node B System 1 System 3 Node C System 1 System 4 Node1 External Connection Sys Func L Sys Func M Interface 1 Interface 4 Sys Func N Sys Func L Sys Func M Sys Func H Sys Func I Sys Func J Interface 5 Key Interface 3 47. Systems-Systems Matrix (SV-3) Interface characteristics: Status (e.g., existing, planned, potential, de-activated) Purpose (e.g., C2, intelligence, logistics) Classification level (e.g., Secret, TS/SCI) Means (e.g., Joint Worldwide Intelligence Communications System, SIPRNet). 48. Systems Functionality Description (SV-4) Use Case Diagram – 1/3 User Type A Systems Use Case 2 User Type B Systems Use Case 1 User Type C Systems Use Case 3 49. Systems Functionality Description (SV-4) Class Diagram – 2/3 Systems Use Case 1 Package 3 Package 2 implemented by implemented by Class 1 (from Package 2) Package 1 implemented by Class 2 (from Package 2) uses Class 4 (from Package 2) uses Class 3 (from Package 2) uses uses 50. Systems Functionality Description (SV-4) Collaboration Diagram – 3/3 : Class 1 : Class 2 : Class 4 1 : External Source 2 : External Source 1 : External Sink 2 : External Sink : Class 3 : Data Repository 2: Data Flow 2 3: Data Flow 3 4: Data Flow 4 6: Data Flow 6 8: Data Flow 8 7: Data Flow 7 1: Data Flow 1 5: Data Flow 5 9: Data Flow 9 10: Data Flow 10 51. Operational Activity to Systems Function Traceability Matrix (SV-5) OV-5 High Level Operational Capability SV-1/2 Systems Operational Capability a Operational Capability b Operational Capability c Operational Capability d Operational Capability e Operational Capability f Operational Capability g System 1 System 2 System 3 System 4 System 5 System 6 52. Systems Data Exchange Matrix (SV-6) Interoperability Level Triggering Event Transaction Type Accuracy Units of Measurement Data Standard Media Type Format Type Content Description Systems Data Exchange Name and Identifier Systems Interface Name and Identifier Nature of Transaction Data Exchange Identification Data Exchange Identification Interface Identification 53. Systems Data Exchange Matrix (SV-6) Cont’d Size Throughput Timeliness Periodicity Receiving System Function Name and Identifier Receiving System Name and Identifier Sending System Function Name and Identifier Sending System Name and Identifier Performance Attributes Consumer Producer Security Standard Release-ability Classification Caveat Classification Protection (Type Name, Duration, Date) Non-Repudiation Consumer Non-Repudiation Producer Integrity Criticality Dissemination Control Confidentiality Availability Access Control Security Information Assurance 54. Performance Parameters Matrix (SV-7) Hardware Element 1 Maintainability Availability System Initialization Time Data Transfer Rate Program Restart Time S/W Element 1 / H/W Element 1 Data Capacity (e.g., throughput or # of input types) Automatic Processing Responses (by input type, # processed/unit time) Operator Interaction Response Times (by type) Effectiveness Availability Mean Time Between S/W Failures Organic Training S/W Element 2 / H/W Element 1 System Name Time 0 (Baseline) Time 1 Time n (Objective) Performance Thresholds/Measures Hardware Element 2 55. Systems Evolution Description (SV-8) LEGACY MAINFRAME SYSTEM FEDERATED DISTRIBUTED SYSTEM CLIENT/SERVER PLATFORMS, LAN, & MIDDLEWARE INSTALLED SEGMENT 1 APPLICATIONS & UNIQUE DATA CONVERTED TO CLIENT/SERVER SEGMENT 2 APPLICATIONS & UNIQUE DATA CONVERTED TO CLIENT/SERVER SEGMENT 3 APPLICATIONS, & UNIQUE DATA CONVERTED TO CLIENT/SERVER COMMON DATA CONVERTED TO SHARED DATA SERVER NEW FUNCTION 1 & UNIQUE DATA IMPLEMENTED ON CLIENT SERVER (& INTEGRATED WITH COMMON DATA ON MAINFRAME) NEW FUNCTION 2 & UNIQUE DATA IMPLEMENTED ON CLIENT SERVER (& INTEGRATED WITH COMMON DATA ON MAINFRAME) V 1.0 V 1.1 V 1.2 V 1.3 V 1.4 V 2.0 +6 MO. +12 MO. +18 MO. +24 MO. +36 MO. +48 MO. +60 MO. 56. Systems Technology Forecast (SV-9) Fiber optic connections available for most telecommuting staff Cable modem service available for most telecommuting staff Networks Disk storage capacity doubles again 5G PCMCIA type 2 card available Persistent Storage Thin screen LED monitors become price competitive for desktops Conventional CRT technology monitors for desktops become obsolete Thin screen CRT monitors for PC desktops become price competitive User Interface External Environment Intel IA-64 becomes standard processor for desktops Initial use of quantum computing technologies Physical Environment Next MS Windows server upgrade expected Next MS Windows desktop upgrade expected Next Red Hat Linux major release expected Operating System Oracle 9i available MySQL (Open Source DBMS) available Data Management Application Platform Microsoft Office available for Linux E-mail on wireless PDAs commonplace Microsoft Office 2000 stable enough for full scale implementation Microsoft Office 2000 available (for Windows 2000) Support Applications Application Software LONG TERM (12-18 Months) MID TERM (6-12 Months) SHORT TERM (0-6 Months) TECHNOLOGY FORECASTS TRM TECHNOLOGY CATEGORY 57. Systems Functionality Sequence and Timing Descriptions (SV-10) State 2 State 1 Event[ Guard Condition ] / Action : Systems Node A : Systems Node B : Systems Node C Message 1 Time 1 Message 2 Time 2 {formula relating Time 1 to Time 2} Message 3 Time n Time 3 Message 4 Message 5 Time 4 {formula relating Time 3 to Time 4} Message 6 Message 7 Message 8 58. Physical Schema (SV-11) 59. DODAF UML Extensions 1/2 Currently, the UML specification ties the deployment diagram to choices of hardware and software, and thus forces the use of deployment diagrams as implementation level descriptors of the technology For the DODAF, nodes in a deployment diagram are associated with systems which are in turn associated with operational activities (use cases) 60. DODAF UML Extensions 2/2 Need to assign or associate systems which may consist of combinations of hardware and software (stereotyped components), to physical locations (stereotyped deployment nodes), to organizations (actors, roles) responsible for conducting the operational activities, and to operational activities (use cases), without having to develop class diagrams as use case realizations that compose components. Solution: The above relationships from organizations (actors), to operational activities (use cases), to systems (components), to systems nodes (deployment nodes) should be specified and maintained by the UML and UML modeling tools, without forcing the architect to realize use cases in class diagrams that detail system behavior. The use case model element should have a direct residing-contained relationship with a component. Actors should have a supported-by relationship with a component. 61. Volume I: Definitions and Guidelines Purpose – Guidance on Value of architectures Architecture measures Framework overview and the six-step process Audience Decision makers Managers 62. Volume II: Product Description Purpose Definition, description, and intended use for each Framework product Description of product and architecture data element relationships Description of corresponding CADM entities and relationships 63. Volume II: Product Description Audience for Volume II: For the manager , product definition and purpose section: Provide a brief overview of architecture products, Describe level of effort involved in developing each product, Describe potential uses of architecture products Allow assessment of products needed to support decisions 64. Volume II: Product Description Audience for Volume II (cont’d) For the architect and engineering team, a detailed description, and architecture data element definitions section: Allow identification of products to be included in the architecture based on architecture’s intended use Facilitate determination of architecture data needs Allow identification of sources for the architecture data Allow analysis and comparison of the data gathered Facilitate composition of data into architecture products 65. Volume II: Product Description Audience for Volume II (cont’d) For the architecture data modelers, tool developers, and engineers , a CADM entities and relationships section: Facilitate implementation of a CADM compliant architecture Modeling tool Facilitate implementation of a CADM compliant architecture data repository 66. Deskbook: Architecture Guidance Purpose: provide supplementary guidance on Developing architectures Using architectures Incorporating Security into architectures Audience Managers Architects Engineers 67. Key Changes in Volume I Overview of DoD and Federal policies concerning architectures Information on the value of architectures, architecture measures, and use of architectures to support DoD processes Introduction to DoD Architecture Repository System (DARS) 68. Key Changes in Volume II Data element definitions internally consistent across products Greater emphasis on architecture data underlying the architecture products Data element tables and element attribute definitions CADM section and corresponding entities Guidance on developing architecture products using UML Section on product and data element interrelationships Technical View is re-titled the Technical Standards View. The acronym remains TV 69. Deskbook (New Volume) Supplementary Material – Topics Included An example architecture using two different approaches (Structured Analysis and Object Orientation) Some techniques for using architecture information to support DoD processes. These include: Navy’s Mission Capability Package analysis approach Air Force’s Task Force capability-based analysis OASD(C3I)/J6 Key Interface process for addressing interoperability at interfaces Key Interface Profiles for addressing interoperability at interfaces Architecture input to C4I Support Plans Guidance on using architectures in the Capital Planning Process Architecture Perspective on Net-centric Operations and Warfare (NCOW) Guidance on security (information assurance) issues with respect to architecture The Role of Humans in Architectures General information on automated tools