Department of Defense
INSTRUCTION
NUMBER8410.03
August 29, 2012
DoD CIO SUBJECT: Network Management (NM)
References: See Enclosure 1
1. PURPOSE. This Instruction, issued under the authorities of DoD Directive (DoDD) 5144.1 (Reference (a)) and DoDD 8000.01 (Reference (b)):
a. Establishes policy and assigns responsibility for planning, implementing, executing, and maintaining NM for the Global Information Grid (GIG) as an integral part of GIG Enterprise Management (GEM).
b. Supplements the overarching guidance for NetOps contained in DoD Instruction (DoDI) 8410.02 (Reference (c)) by directing that NM data be shared and that NM and spectrum management (SM) systems be integrated.
c. Supplements the guidance contained in DoDI 8500.02 (Reference (d)) by specifically requiring the adoption of mechanisms and processes for NM systems, (e.g., automated configuration management (CM) and policy based network management (PBNM) capabilities).
2. APPLICABILITY. This Instruction:
a. Applies to OSD, the Military Departments, the Office of the Chairman of the Joint Chiefs of Staff (CJCS) and the Joint Staff, the Combatant Commands, the Office of the Inspector General of the Department of Defense, the Defense Agencies, DoD Field Activities, and all other organizational entities within the DoD (herein after referred to collectively as the “DoD Components”).
b. Applies to all DoD NM systems and associated technology, processes, personnel, and organizations that receive, process, store, display, or transmit DoD information, regardless of classification or sensitivity, to include NM systems operated by a contractor or other entity on behalf of DoD and any NM system interfaces to DoD mission partners.
c. Shall not alter or supersede the existing authorities and policies of the Director of National Intelligence regarding the protection of sensitive compartmented information (SCI) and special
access programs (SAP) for intelligence as directed by Executive Order 12333 (Reference (e)) and other laws and regulations. The application of the provisions and procedures of this Instruction to SCI or other SAP for intelligence information systems is encouraged where they may complement or discuss areas not otherwise specifically addressed.
3. DEFINITIONS. See Glossary.
4. POLICY. It is DoD policy that:
a. All NM systems shall be capable of distributed network control and facilitate net-centric sharing of network configuration, status, security, performance, utilization, and mission impact data with authorized users in accordance with (IAW) section 2 of Enclosure 3 of this Instruction.
b. Systems that use Simple Network Management Protocol (SNMP) shall use the latest version as the target protocol version IAW section 3 of Enclosure 3.
c. DoD Components operating NM systems shall develop service level agreements (SLAs) or similar agreements to ensure quality of service, interoperability, and availability of NM data exchanged between NM systems and with any authorized user IAW section 4 of Enclosure 3.
d. NM systems shall incorporate mechanisms or processes that ensure resiliency and continuity of operations in the event of a failure, loss, or disruption of NM capabilities due to a cyber attack or other manmade or natural occurrenc
e.
e. NM systems shall have and use integrated automated CM and PBNM capabilities to improve DoD’s ability to rapidly and consistently respond to information assurance (IA) events and maintain network availability and performance.
f. NM and SM systems shall be integrated, as appropriate, to create information technology (IT) resource management capabilities that provide the warfighter with enhanced situational awareness (SA) to support common understanding, planning, and monitoring; distributed network and spectrum control; and reduce life cycle costs.
g. NM interfaces to DoD mission partners (e.g., coalition and industrial suppliers) shall leverage and employ industry and commercial data standards, architectures, models, and exchange mechanisms to the maximum extent possible.
5. RESPONSIBILITIES. See Enclosure 2.
6. RELEASABILITY. UNLIMITED. This Instruction is approved for public release and is available on the Internet from the DoD Issuances Website at https://www.doczj.com/doc/444637422.html,/whs/directives.
7. EFFECTIVE DATE. This Instruction:
a. Is effective August 29, 2012.
b. Must be reissued, cancelled, or certified current within 5 years of its publication in accordance with DoD Instruction 5025.01 (Reference (f)). If not, it will expire effective August 29, 2022and be removed from the DoD Issuances Website.
Teresa M. Takai
DoD Chief Information Officer
Enclosures
1. References
2. Responsibilities
3. Procedures
Glossary
TABLE OF CONTENTS
ENCLOSURE 1: REFERENCES (5)
ENCLOSURE 2: RESPONSIBILITIES (7)
DoD CHIEF INFORMATION OFFICER (DoD CIO) (7)
DIRECTOR, DISA (8)
UNDER SECRETARY OF DEFENSE FOR ACQUISITION, TECHNOLOGY, AND LOGISTICS (USD(AT&L)) (9)
DIRECTOR, OPERATIONAL TEST AND EVALUATION (DOT&E) (10)
UNDER SECRETARY OF DEFENSE FOR INTELLIGENCE (USD(I)) (10)
DIRECTOR, DEFENSE INTELLIGENCE AGENCY (DIA) (10)
DIRECTOR, NATIONAL SECURITY AGENCY (DIRNSA)/CHIEF, CENTRAL SECURITY SERVICE (CHCSS) (10)
HEADS OF THE DEFENSE INTELLIGENCE COMPONENTS......... . (10)
HEADS OF THE DoD COMPONENTS (10)
CJCS (12)
COMMANDERS OF THE COMBATANT COMMANDS (12)
CDRUSSTRATCOM (12)
ENCLOSURE 3: PROCEDURES (14)
GENERAL (14)
NM DATA EXCHANGE GUIDELINES (14)
NM USE OF SNMP (16)
SLAs (17)
NM SECURITY (19)
NM STANDARDS AND SCHEMAS FOR TACTICAL EDGE NE (20)
GLOSSARY (21)
PART I: ABBREVIATIONS AND ACRONYMS (21)
PART II: DEFINITIONS (23)
ENCLOSURE 1
REFERENCES
(a) DoD Directive 5144.1, “Assistant Secretary of Defense for Networks and Information
Integration/DoD Chief Information Officer (ASD(NII)/DoD CIO),” May 2, 2005
(b) DoD Directive 8000.01, “Management of the Department of Defense Information
Enterprise,” February 10, 2009
(c) DoD Instruction 8410.02, “NetOps for the Global Information Grid (GIG),” December 19,
2008
(d) DoD Instruction 8500.02, “Information Assurance (IA) Implementation,” February 6, 2003
(e) Executive Order 12333, “United States Intelligence Activities,” December 4, 1981, as
amended
(f) DoDI 5025.01, “DoD Directives Program,” October 28, 2007
(g) DoD Directive 8320.02, “Data Sharing in a Net-Centric Department of Defense,”
December 2, 2004
(h) DoD Directive 5015.2, “DoD Records Management Program,” March 6, 2000
(i) DoD Instruction 4650.01, “Policy and Procedures for Management and use of the
Electromagnetic Spectrum,” January 9, 2009
(j) DoD Instruction 4630.8, “Procedures for Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS),” June 30, 2004
(k) DoD Instruction 5000.02, “Operation of the Defense Acquisition System,” December 8, 2008
(l) DoD Directive 5105.19, “Defense Information Systems Agency (DISA),” July 25, 2006 (m) Internet Engineering Task Force Request For Comment 2578, “Structure of Management Information Version 2 (SMIv2),” April 1999
(n) DoD Instruction 8320.05, “Electromagnetic Spectrum Data Sharing,” August 18, 2011 (o) DoD Directive 5143.01, “Under Secretary of Defense for Intelligence (USD(I)),”
November 23, 2005
(p) Memorandum of Agreement between the Assistant Secretary of Defense for Networks and Information Integration and the Intelligence Community (IC) Chief Information Officer for “Sharing Network Management and Computer Network Defense Information,” June 24, 2005
(q) National Security Directive 42, “National Policy for the Security of National Security Telecommunications and Information Systems,” July 5, 1990
(r) Intelligence Community Directive 502, "Integrated Defense of the Intelligence Community Information Environment," March 11, 2011
(s) DoD Instruction 5000.64, “Accountability and Management of DoD Equipment and other Accountable Property,” May 19, 2011
(t) DoDM 5200.01, Volume 1, “DoD Information Security Program: Overview, Classification, and Declassification,” February 24, 2012
(u) TeleManagement Forum, Information Framework (SID), GB922, Release 9.5
(v) Desktop Management Task Force, Common Information Model, version 2.31.1
(w) NIST Special Publication (SP) 800-126 rev2, The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2, Published: September 30, 2011
(x) DoD Discovery Metadata Specification, Version 4.0.1, November 11, 2011
(y) International Telegraph and Telephone Consultative Committee Recommendation X.731, “Information Technology – Open Systems Interconnection – Systems Management: State Management Function,” January 1992
(z) International Telecommunication Union – Telecommunication Standardization Sector Recommendation M.3342, “Guidelines for the definition of SLA representation templates,”
July 2006
(aa) TM For um GB917 Release 3.0, “SLA Management Handbook,” January 2011
(ab) DISA Security Technical Implementation Guides, Network Infrastructure1
(ac) US Strategic Command Instruction 720-1, “Global Information Grid (GIG) NetOps Security Classification Guide (SCG),” July 15, 2009
(ad) DoD 8570.01-M, “Information Assurance Workforce Improvement Program,” December 19, 2005
(ae) DoD 5200.2-R, “Personnel Security Program,” January 1, 1987
(af) Directive-Type Memorandum 09-016, “Suppl y Chain Risk Management (SCRM) to Improve the Integrity of Components Used in DoD Systems,” March 25, 2010
(ag) DoD Instruction 5200.39, “Critical Program Information (CPI) Protection within the Department of Defense,” July 16, 2008
(ah) Joint Publication 1-02, “Department of Defense Dictionary of Military and Associated Terms,” current edition
(ai) Internet Engineering Task Force Request For Comment 2570, “Introduction to Version 3 of the Internet-standard Network Management Framework,” April 1999
1 https://www.doczj.com/doc/444637422.html,/stigs/stig/index.html
ENCLOSURE 2
RESPONSIBILITIES
1. DoD CHIEF INFORMATION OFFICER (DoD CIO). The DoD CIO, shall:
a. Provide strategy, policy, oversight, and guidance for NM capability, planning, definition, and implementation across the DoD Information Enterprise and GIG IAW Reference (b).
b. In coordination with Under Secretary of Defense for Acquisition, Technology, and Logistics (USD(AT&L)) and the Heads of the DoD Components, develop:
(1) End-to-end NM architectures and strategies that support efficient, effective, and secure NM operations in tactical and non-tactical networks and improve interoperability across NM systems.
(2) Mission-driven NM metrics for tactical and non-tactical networks and NM systems that enable consistent assessments of DoD network protection and performance.
(3) Strategies and architectures for IT resource management capabilities that efficiently and effectively integrate NM and SM systems across doctrine, organization, training, materiel, leadership and education, personnel and facilities (DOTMLPF).
c. Ensure that the Defense Information Systems Agency (DISA), in coordination with the other DoD Components, develops, coordinates, and establishes NM data schemas that facilitate the sharing of tactical edge NM information within tactical edge networks and with NM systems that manage non-tactical edge networks IAW DoDD 8320.02 (Reference (g)).
d. Ensure that NM data schemas, technical standards and specifications, interface definitions, and other related information are available to all authorized users from the DoD Metadata Registry (MDR), Defense Technical Information Center, or other appropriate websites and repositories.
e. Develop, in coordination with the Heads of the DoD Components, guidelines for network SLAs, a DoD service level management governance framework, and a process for reviewing and coordinating SLAs.
f. Develop, in coordination with the Heads of the DoD Components, NM records and information management and retention guidelines IAW DoDD 5015.2 (Reference (h)).
g. Ensure that NM and SM capabilities are acquired in coordination with USD(AT&L) and are managed, integrated, and synchronized consistent with Reference (b), and DoDIs 4650.01, 4630.08, and 5000.02 (References (i), (j), and (k)).
h. Develop, in coordination with the Heads of the DoD Components, architectures and standards for automated CM and PBNM capabilities based on the results of the USD(AT&L) assigned responsibilities contained in this Instruction.
2. DIRECTOR, DISA. The Director, DISA, under the authority, direction, and control of the DoD CIO, and in addition to the responsibilities in sections 8 and 9 of this enclosure and IAW DoDD 5105.19 (Reference (l)), and in coordination with the Heads of DoD Components, shall:
a. Establish and maintain repositories of NM data schemas, technical standards and specifications, interface definitions, and SNMP management information bases (MIBs) based upon security classifications, to include proprietary SNMP MIBs IAW the Internet Engineering Task Force Request For Comment 2578, “Structure of Management Information Version 2 (SMIv2)” (Reference (m)).
b. Develop and maintain, with support from the DoD Components, the definition of NM data exchanges, translations, and associated data schemas among all NM systems, to include tactical edge NM systems. This effort shall leverage and employ industry and commercial data standards, architectures, models, and exchange mechanisms to the maximum extent possible.
c. Define common data standards for sharing information and data between NM and SM systems IAW DoDI 8320.05 (Reference (n)).
d. Establish and maintain a standard dictionary for use in constructing standard NM data schemas for exchanging NM information between NM systems and for exposing NM data to non-NM systems.
e. Establish naming conventions and standards that facilitate the sharing of NM information and control capabilities among NM systems across established NetOps operational hierarchies and NM domains.
f. Establish and maintain definitions and interface control documents for standard mechanisms for exchanging NM information between NM systems and for exposing data to non-NM systems.
g. Create, manage, and maintain a common repository based upon security classifications within the MDR for all data-exchange schemas and SNMP MIBs used by NM systems, including supporting documentation and interface characteristics and specifications.
h. Participate in applicable standards bodies and organizations to advocate for and aid in developing standards, protocols, and mechanisms for translating NM information from current formats (e.g., SNMP) to ones that facilitate net-centric information sharing (e.g., extensible markup language).
i. Develop, in coordination with the DoD Components, a GIG technical profile (GTP) to define the interface specifications for exchanging data between NM systems.
j. Develop and promulgate DoD-wide standards and guidelines for use of NM protocols (such as SNMP or network configuration protocol) for communication of NM information between NM systems and their managed network elements (NEs).
k. Develop, in coordination with the Commander, U.S. Strategic Command (USSTRATCOM), technical guidance for integrating and correlating NM and SM capabilities to enable near real-time end-to-end network SA throughout the GIG.
l. Support the USD(AT&L) in reviewing and studying automated CM and PBNM capabilities and standards.
m. Develop and promulgate technical guidance and architectures for developing and implementing automated CM and PBNM systems.
n. Establish and maintain a central repository of SLAs.
3. USD(AT&L). The USD(AT&L) shall:
a. Provide coordination and support to ensure that any policies, guidance, or requirements proposed by the DoD CIO regarding SM and NM requirements impacting access to defense networks and vendor facing applications by members of the Defense Industrial Base (DIB) will not place any undue burdens on industry.
b. Prepare and coordinate acquisition and contracting policy, procedures, and regulation among DIB members and Federal partners necessary to implement this Instruction.
c. Coordinate with DIB members supplying materiel and services, to ensure an executable and affordable migration strategy to meet SM and NM requirements resulting from the implementation of this Instruction.
d. Implement automated CM and PBNM capabilities and standards in new or modified NM systems, including but not specifically limited to determining architectures and technical approaches for:
(1) Network traffic bandwidth prioritization.
(2) Contingency-based configuration changes that will satisfy a typical joint operation, including potential coalition partners or similar.
(3) Implementing automated configuration change technologies.
(4) Determining standard methods for human override of automated configuration changes.
4. DIRECTOR, OPERATIONAL TEST AND EVALUATION (DOT&E). The DOT&E shall:
a. Ensure processes, procedures, and infrastructure are available to operationally test and evaluate NM capabilities that are developed and acquired.
b. Conduct periodic assessments of NM processes, procedures, and capabilities as requested by the DoD CIO.
5. UNDER SECRETARY OF DEFENSE FOR INTELLIGENCE (USD(I)). The USD(I) shall serve as the DoD focal point to the Intelligence Community (IC) for NM policy and oversight matters relating to intelligence information sharing and interoperability of Defense intelligence systems and processes IAW DoDD 5143.01 (Reference (o)).
6. DIRECTOR, DEFENSE INTELLIGENCE AGENCY (DIA). The Director, DIA, under the authority, direction, and control of the USD(I) and as the Manager of the SCI component of the GIG shall, in addition to the responsibilities in sections 8 and 9 of this enclosure, interact with the Director of National Intelligence to facilitate coordination and sharing of DoD SCI network status and SA information IAW the memorandum of agreement between the DoD CIO and the IC CIO (Reference (p)).
7. DIRECTOR, NATIONAL SECURITY AGENCY (DIRNSA)/CHIEF, CENTRAL SECURITY SERVICE (CHCSS). The DIRNSA/CHCSS, under the authority, direction, and control of the USD(I), in addition to the responsibilities in sections 8 and 9 of this enclosure, and, consistent with the National Manager responsibilities assigned to DIRNSA by National Security Directive 42 (Reference (q)), shall lead, with the support of the other DoD Components, the development of suitable technical standards; administrative guidance; key-management protocols, devices, and systems; encryption methods; and other items as required to enable NM systems and the NE they manage to comply with applicable IA controls.
8. HEADS OF THE DEFENSE INTELLIGENCE COMPONENTS. The Heads of the Defense Intelligence Components shall execute their NM responsibilities consistent with Intelligence Community Directive 502 (Reference (r)).
9. HEADS OF THE DoD COMPONENTS. The Heads of the DoD Components shall:
a. Execute NM within the portions of the Defense Information Enterprise within their assigned area of responsibility (AOR) IAW Reference (b) and in support of Combatant Commanders’ responsibilities.
b. Support DoD CIO, USD(AT&L), Director, DISA, and Commander, USSTRATCOM (CDRUSSTRATCOM) in developing mission-driven metrics and end-to-end NM architectures
and strategies that support efficient NM operations in tactical and non-tactical networks to improve interoperability and integration across NM systems.
c. Develop strategies and architectures for IT resource management capabilities that efficiently, effectively, and securely integrate NM and SM systems across DOTMLPF.
d. Support DISA in developing and maintaining NM standards, specifications, and interfaces to include defining extensions to baseline NM data-exchange schemas necessary to enable and facilitate the exchange and sharing of NM information and data with tactical edge NM systems.
e. Implement common data-exchange schemas to ensure interoperability of NM systems sufficient to execute the SLAs or similar agreements IAW section 3 of Enclosure 3 of this Instruction. Individual NM systems may either directly implement the schemas or may provide translation to and from these schemas.
f. Plan, organize, procure, develop, test, implement, and operate NM capabilities within established NetOps operational hierarchies and NM domain structures.
(1) Support CDRUSSTRATCOM in the development and vetting of NM data standards and sharing mechanisms.
(2) Ensure Component NM systems comply with USSTRATCOM-approved NM data-exchange schemas and standards-based data sharing mechanisms.
(3) Ensure that new or modified NEs are discoverable, manageable, and comply with applicable IA controls in accordance with Reference (d).
g. Support CDRUSSTRATCOM in establishing NetOps hierarchies that fully consider NM along with network defense and content management.
h. Support CDRUSSTRATCOM in developing operational requirements for automated CM and PBNM.
i. Ensure that NM systems are resilient to manmade or natural events that may cause failure, loss or disruption of NM capabilities.
j. As needed and with DISA support, develop standard NM information and data models to include NM MIB standards for tactical edge NEs.
(1) Standards shall consider the unique properties of tactical networking, including but not limited to the ad-hoc nature of such networks, the requirement for NEs to connect and disconnect at random due to mobility-related constraints, the often limited bandwidth available, and operational requirements to remain in a non-transmitting state for extended periods of time.
(2) Where appropriate, these standards shall be established jointly, maintained by DISA, and incorporated into the baseline schemas for NM.
k. Provide the NM and SM data necessary to fulfill the commander’s critical information requirements in support of established DoD cyberspace operational hierarchies.
l. Ensure, in coordination with DISA, all DoD equipment containing or potentially containing personally identifiable information and other data of a sensitive nature is managed in accordance with DoDI 5000.64 (Reference (s)).
10. CJCS. The CJCS, in addition to the responsibilities in section 8 of this enclosure and in coordination with the other Heads of the DoD Components, shall:
a. Establish and issue priorities for the collection and sharing of NM data.
b. Develop and promulgate joint NM tactics, techniques, and procedures.
c. In coordination with the Combatant Commanders, establish requirements for sharing NM information and data with coalition partner networks.
11. COMMANDERS OF THE COMBATANT COMMANDS. The Commanders of the Combatant Commands, in addition to the responsibilities in section 8 of this enclosure, shall support the Joint Staff in establishing requirements for sharing NM information and data with coalition partner networks.
12. CDRUSSTRATCOM. The CDRUSSTRATCOM, in addition to the responsibilities in sections 8 and 10 of this enclosure, shall:
a. Develop and issue guidance for ensuring uninterrupted, end-to-end monitoring and control of all operational DoD networks.
b. Develop, publish, and enforce standard processes for the sharing of NM data about readiness and operating status of all DoD networks.
c. Establish clear lines of authority and responsibility for NM across all DoD network domains and with DoD mission partners.
d. Develop, in coordination with the Director, DISA, operational guidance for integrating and correlating NM capabilities to enable near real-time end-to-end network SA.
e. Develop, in coordination with the other Heads of the DoD Components, and issue security classification guidelines for NM and SM information IAW DoDM 5200.01, Volume 1 (Reference (t)).
f. Approve NM data schemas and sharing mechanisms.
g. Develop, in coordination with the other Heads of the DoD Components, automated CM and PBNM operational requirements.
ENCLOSURE 3
PROCEDURES
1. GENERAL. The procedures in this enclosure are applicable to all NM systems, including those intended for the tactical environment, except as specifically noted in each section.
2. NM DATA EXCHANGE GUIDELINES
a. The DoD shall adopt and implement the TeleManagement (TM) Forum Information Framework (formerly known as the Shared Information and Data Model) and the Desktop Management Task Force (DMTF), Common Information Model (CIM) as the foundation NM information and data models and the National Institute of Standards and Technology (NIST) Security Content Automation Protocol as the baseline protocol and standards for sharing security management information sharing (References (u), (v), and (w)). Drawing on the DISR, other industry-standard information and data models (e.g., Internet Engineering Task Force (IETF), DMTF CIM, IETF SMIv2) and protocols (e.g., International Telecommunications Union-Telecommunication Cybersecurity Information Exchange (ITU-T CYBEX)) may be used to tailor those baselines where application requirements and other circumstances so warrant. Only if existing standards cannot be extended shall DoD Components adopt and implement non-standards based data schemas and exchange mechanisms.
b. The CDRUSSTRATCOM, IAW Reference (c) and functioning IAW Reference (g), shall vet and approve NM data schemas and sharing mechanisms.
c. DoD programs of record (POR) shall adopt and implement NM data schemas and net-centric sharing mechanisms that have been approved by CDRUSSTRATCOM. In situations where it is determined that adopting approved NM data schemas and net-centric sharing mechanisms would result in unacceptable delay or increased costs to a POR, a request for waiver will be submitted via the applicable acquisition oversight process.
(1) Where standards or data schemas are not available or have not been approved, program offices shall work with DISA to identify and vet program specific data standards, schemas, and exchange mechanisms prior to them being submitted to CDRUSSTRATCOM for approval.
(2) Requests for approval of data schema or sharing mechanism submitted to USSTRATCOM must be reviewed and adjudicated within 90 days of their submittal to ensure that program development timelines should not be adversely impacted.
d. NM systems shall use Enterprise Services (ES) that have been approved by the DoD CIO to enable and facilitate the discovery, sharing, and collaborative use of NM data among all authorized users.
e. All approved NM data-exchange schemas shall be registered in the DoD MDR to include associated metadata schemas and discovery metadata and shall be made available to all DoD Components and authorized mission partners.
(1) NM data elements shall be made visible by creating and associating metadata (referred to as “data tagging”), including discovery metadata.
(2) Discovery metadata shall conform to the DoD Discovery Metadata Specification (Reference (x)).
(3) DoD metadata standards shall comply with applicable national and international consensus standards for metadata exchange whenever possible IAW Reference (g).
(4) All metadata shall be discoverable, searchable, and retrievable using DoD-wide capabilities.
(5) Metadata shall include the classification level of each NM data element.
(6) Metadata shall be classified when any single item of metadata or a compilation of metadata meets the requirements for classification, IAW Reference (t).
f. NM data-exchange schemas shall identify and define similar or identical parameters in the same way. Resolution of parameter naming and definition shall be the responsibility of CDRUSSTRATCOM working in coordination with other affected community of interests.
g. The specific data and information available from an NM system varies based on system capabilities and implementation but at a minimum NM systems should be capable of collecting and reporting the following information about the NEs they manage:
(1) Operational configuration.
(2) Current operational state.
(3) Current usage state.
(4) Available NE capacity and percent of capacity currently committed.
h. NE data will normally be collected through the device’s MIB values for SNMP managed devices or by other means for non-SNMP managed devices and the resulting information shall be shared with authorized users via an ES or other net-centric data sharing mechanism.
i. The CDRUSSTRATCOM, in coordination with DISA and the DoD Components, shall define a minimum set of standards and values for reporting information based on International Telegraph and Telephone Consultative Committee (CCITT) Recommendation X.731 (Reference (y)) and other applicable IETF, Distributed Management Task Force, and TM Forum standards.
3. NM USE OF SNMP
a. All SNMP MIBs used in the DoD shall comply with technical standards in the DISR and DISA Security Technical Implementation Guides (STIGs).
b. All MIBs along with full descriptions of their use and format shall be stored in an MIB registry managed and published by DISA.
c. Where possible, elements in multiple MIBs that refer to the same parameter shall be formatted and identified the same way. Standard formats and identifications shall be maintained in a DoD-published MIB data format and dictionary established and maintained by DISA.
d. New SNMP managed resources and management applications shall use the latest approved version of SNMP, to take advantage of the additional security features provided with this version of the protocol. Existing systems that use SNMP shall transition to the latest approved SNMP version when feasibl
e.
e. The latest version of SNMP shall be implemented with a security model appropriate to the security of the network rather than the default model.
f. Existing systems that use SNMP v1 or v2c shall implement the following security precautions in the period prior to transition to the latest approved version of SNMP:
(1) NEs requiring SNMP management shall be properly configured with appropriate read-only and read-write community names (commonly referred to as “community strings”).
(2) Read-only and read-write SNMP community strings for a managed device shall be different.
(3) Where possible, a different string (or strings) shall be utilized for each NE, or at minimum for each area of the network being managed. For instance, if an authorized user requests access to information about DISN, they could be given a read-only community string and a list of devices that it can be used to access. In addition to enabling access, this approach allows network managers to quickly and easily isolate portions of the network and serves to keep the number of required community strings to a manageable level.
(4) SNMP community strings shall be safeguarded and protected against compromise at the level of the operational network.
(5) SNMP community strings shall meet the minimum password length and composition requirements required by applicable IA controls.
(6) The community strings and management passwords shall be changed at least annually and when there is a possibility that one has been compromised.
(7) The community strings shall be modified from default settings –default “public” and “private” strings shall not be utilized.
(8) Periodic SNMP polling should be done with a read-only community string, and read-write strings should be used only for write operations, based on the capabilities of the NM system.
(9) Unauthorized attempts to access SNMP managed NE shall be aggressively monitored and reported.
(10) Device, account, and application passwords will not be passed over SNMP until the transition to the latest version is accomplished.
g. Access control lists shall be implemented on SNMP managed NEs, where possible, to restrict access to only authorized NM operators and NM systems.
4. SLAs
a. NM systems shall be located within the network topology in a manner that ensures they can monitor and report on SLA compliance.
b. NM SLAs shall at a minimum address the following areas identified in International Telecommunications Union – Telecommunications Recommendation M.3342 (Reference (z)) and TM Forum GB917 Release 3.0 (Reference (aa)):
(1) Identification of the organizations between which the agreement is established, to include technical and organizational points of contact.
(2) A description of the NM services that will be provided along with scope, limitations, and other terms of reference that might be needed.
(3) A basic description of the NM system and supporting equipment information and who is responsible for providing, maintaining, and operating it.
(4) Detailed explanations of the expected levels and quality of NM services that will be provided.
(5) How NM service levels will be monitored and reported. This section must include: where, how, and in what format NM information and data will be collected; how often it will be collected; how it will be shared with the customer; how often it will be shared with the customer; how NM information and data will be archived; and duration archived information will be retained IAW Reference (h). This section will define for all parties:
(a) The characteristics of the NM information to be exchanged (e.g., data schema(s) used, specialized data formatting (if any), and any non-standard characteristics).
(b) Required NM data update rates.
(c) Maximum allowable time from when an event takes place to when it is reported by the NM system, as well as the location of event.
(d) Location of the NM event.
(e) Allowable NM system initialization time and data sync (or data re-sync due to NM and radio reconnection).
(f) Required local event storage requirements (if any).
(g) Reporting formats, destinations, and update rates (if finished reports are to be provided.
(h) Mechanisms for enforcement, auditing, and assurance.
(6) A description of NM system backup, recovery and continuity of operations requirement.
(7) Procedures for changing and terminating the SLA.
(8) A description of the remedies available to the customer in the event the NM system does not perform as agreed.
c. SLAs and other agreements that include tactical edge and non-tactical edge networks shall take into consideration the unique characteristics of tactical edge networks (e.g., dynamic, ad-hoc, bandwidth constrained, and intermittent connections); however these characteristics shall not be used to exempt tactical edge and non-tactical edge networks from the requirement to have SLAs. Implementation of SLAs for tactical edge and non-tactical edge networks shall not impact network or mission effectiveness.
d. NM SLAs and other agreements shall be structured to complement or extend other SLAs entered into by DoD Components. If desired, an NM SLA or equivalent could be made part of the overall SLA, or similar agreement addressing the networks being managed.
e. NM SLAs and other agreements shall establish baseline and minimum service levels and address provisioning and measurement of the following network performance parameters:
(1) Network latency and packet loss on per-hop and end-to-end basis by traffic type.
(2) Minimum and maximum bandwidth provided.
(3) Mean time between failures of network equipment or connectivity.
(4) Mean time to repair failures in network equipment or connectivity.
(5) Throughput of a given network node, by traffic type.
(6) Percentage of available bandwidth consumed on a given link, by traffic type.
(7) Fault status, by node priority.
(8) Packet error rate and bit error rate (average and standard deviation) through a given network node.
(9) Quality of service requirements for NM and control plane traffic.
5. NM SECURITY
a. Data exchanges between NM systems shall be encrypted per DISA Security Technical Implementation Guides Network Infrastructure (Reference (ab)) and shall be processed and protected at the appropriate classification level.
b. Management information obtained from NEs shall be classified, stored, processed, and shared IAW the USSTRATCOM GIG NetOps Security Classification Guide (Reference (ac)) and other applicable classification guides. NM data that provides sensitive operational status of the network or the status of the network’s ability to support real-world operations shall be protected as sensitive information (minimum) or at an appropriate higher classification level based on the classification of the network it is derived from.
c. NM system operator and supervisory positions (e.g., system administrators, network managers and controllers, router and switch administrators, managers and controllers) performing NM IA functions as defined in DoD 8570.01-M (Reference (ad)) shall be designated IA Technical Category Level 2 and IA Management Category Level 2 positions and as critical sensitive positions as defined by DoD 5200.2-R (Reference (ae)), and military, government civilian, and contractor personnel filling them shall meet all required background checks, training, and certification requirements prior to assuming their duties.
d. Access to NM systems shall be authorized by the appropriate unit level commander responsible for the NM system. Only those users with proper credentials and access authorizations will be granted access to NM systems. NM system users shall comply with the applicable IA training and certification requirements IAW Reference (ad).
e. NM functions are critical within the network infrastructure. Accordingly, supply chain risk management shall be applied to the acquisition of NM functionality IAW Directive-Type Memorandum (DTM) 09-016 (Reference (af)) and DoDI 5200.39 (Reference (ag)).
6. NM STANDARDS AND SCHEMAS FOR TACTICAL EDGE NE. To support end-to-end SA and NM system reporting criteria, common NM standards are required to support spectrum-dependent systems and tactical edge NEs.
a. In consideration of tactical edge NM requirements, the DoD Components with DISA support shall jointly establish NM standards for tactical edge NEs. The standards shall be maintained by DISA and incorporated into the baseline schemas for NM. These standards shall consider the unique properties of tactical networking, including but not limited to:
(1) The ad-hoc nature of such networks.
(2) The requirement for NEs to connect and disconnect at random due to mobility-related constraints.
(3) The often limited bandwidth available.
(4) Operational requirements to remain in a non-transmitting state for extended periods of time.
b. As requested, DISA shall support program managers, in the incorporation of these standards into new or existing programs of record.
美国国防部架构框架（DoDAF）介绍 摘要： DoDAF是由美国国防部的US Undersecretary of Defense for Business Transformation工作小组所制定的系统体系结构框架(Architecture Framework,简称AF)。 关键词： DODAF，C4ISR，美国国防部，架构框架 DoDAF是由美国国防部的US Undersecretary of Defense for Business Transformation工作小组所制定的系统体系结构框架(Architecture Framework,简称AF)。其前身是C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance )体系结构框架。近年来，基于DoDAF而发展出来的有：英国国防部提出的MODAF和NAF (NATO Architecture Framework)。 美国国防部（DoD）于2004年2月颁布了《体系结构框架》的1.0版本用于指导国防指挥 1.DoDAF的演进 C4ISR AF 1.0 ----于1996年6月推出。 C4ISR AF 2.0 ----于1997年12月推出。 DoDAF 1.0 ----于2003年8月推出，增加其运用范围，不局限C4ISR里，可以应用到所有的任务领域（Mission Area）；同时也推出CADM v1.01。 DoDAF 1.5 ----于2007年4月推出，特别强调以网路为中心(Net-Centric)的概念，在体系结构的描述里体现了网络为中心的概念；也推出CADM v1.5以便储存Net-Centric新概念的描述文件。 DODAF2.0----于2009年5月28日推出。 与前几版相比，2.0版主要有以下几点变化： 1)体系结构开发过程从以产品为中心转向以数据为中心，主要是提供决策 数据； 2)三大视图（作战、技术和系统）转变为更为具体的视图。现在的视图有 八种，分别是全视图、数据与信息视图、标准视图、能力视图、作战视
集合与关系《应用离散数学》 第3章 21世纪高等教育计算机规划教材
目录 3.1 集合及其运算 3.2 二元关系及其运算3.3 二元关系的性质与闭包3.4 等价关系与划分 3.5 偏序关系与拓扑排序3.6 函 数 3.7 集合的等势与基数3.8 多元关系及其应用
集合是现代数学中最重要的基本概念之一，数学概念的建立由于使用了集合而变得完善并且统一起来。集合论已成为现代各个数学分支的基础，同时还渗透到各个科学技术领域，成为不可缺少的数学工具和表达语言。对于计算机科学工作者来说，集合论也是必备的基础知识，它在开关理论、形式语言、编译原理等领域中有着广泛的应用。 本章首先介绍集合及其运算，然后介绍二元关系及其关系矩阵和关系图，二元关系的运算、二元关系的性质、二元关系的闭包，等价关系与划分、函数，最后介绍多元关系及其在数据库中的应用等。
3.1 集合及其运算 3.1.1 基本概念 集合是数学中最基本的概念之一，如同几何中的点、线、面等概念一样，是不能用其他概念精确定义的原始概念。集合是什么呢？直观地说，把一些东西汇集到一起组成一个整体就叫做集合，而这些东西就是这个集合的元素或叫成员。 例3.1 （1）一个班级里的全体学生构成一个集合。 （2）平面上的所有点构成一个集合。 （3）方程 的实数解构成一个集合。 （4）自然数的全体（包含0）构成一个集合，用N表示。 （5）整数的全体构成一个集合，用Z表示。 （6）有理数的全体构成一个集合，用Q表示。 （7）实数的全体构成一个集合，用R表示。
（8）复数的全体构成一个集合，用C表示。 （9）正整数集合Z+，正有理数集合Q+，正实数集合R+。（10）非零整数集合Z*，非零有理数集合Q*，非零实数集合R*。（11）所有n 阶(n≥2)实矩阵构成一个集合，用M n(R)表示，即
美国国防部架构框架 D o D介绍 集团公司文件内部编码：（TTT-UUTT-MMYB-URTTY-ITTLTY-
美国国防部架构框架（DoDAF）介绍 摘要：DoDAF是由美国国防部的USUndersecretaryofDefenseforBusinessTransformation 工作小组所制定的系统体系结构框架(ArchitectureFramework,简称AF)。 关键词：DODAF，C4ISR，美国国防部，架构框架 DoDAF是由美国国防部的USUndersecretaryofDefenseforBusinessTransformation工作小组所制定的系统体系结构框架(ArchitectureFramework,简称AF)。其前身是 C4ISR(Command,Control,Communications,Computers,Intelligence,SurveillanceandRec onnaissance)体系结构框架。近年来，基于DoDAF而发展出来的有：英国国防部提出的MODAF和NAF(NATOArchitectureFramework)。 美国国防部（DoD）于2004年2月颁布了《体系结构框架》的1.0版本用于指导国防指挥 1.DoDAF的演进 C4ISRAF1.0----于1996年6月推出。 C4ISRAF2.0----于1997年12月推出。 DoDAF1.0----于2003年8月推出，增加其运用范围，不局限C4ISR里，可以应用到所有的任务领域（MissionArea）；同时也推出CADMv1.01。 DoDAF1.5----于2007年4月推出，特别强调以网路为中心(Net-Centric)的概念，在体系结构的描述里体现了网络为中心的概念；也推出CADMv1.5以便储存Net-Centric新概念的描述文件。 DODAF2.0----于2009年5月28日推出。 与前几版相比，2.0版主要有以下几点变化： 1)体系结构开发过程从以产品为中心转向以数据为中心，主要是提供决策数据；
很详细的系统架构图 专业推荐 2013.11.7
1.1.共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图，上图整体展现说明包括以下几个方面： 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发，从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合，完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类，具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源，我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源，我们将通过全面的接口管理体系进行相应资源采集模板的搭建，采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现，具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用 最终数据将通过内外网门户对外进行发布，相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询，从而有效提升了我局整体应用服务质量。
综上，我们对本次项目整体逻辑架构进行了有效的构建，下面我们将从技术角度对相关架构进行描述。 1.2.技术架构设计 如上图对本次项目整体技术架构进行了设计，从上图我们可以看出，本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。 1.3.整体架构设计 上述两节，我们对共享平台整体逻辑架构以及项目搭建整体技术架构进行了分别的设计说明，通过上述设计，我们对整体项目的架构图进行了归纳如下：
框架结构体系结构设计 第一章建筑设计 1.1 设计资料 建筑设计使用年限50年。年均气温27.6度，最高气温39度，最低气温4.3度。东北风为主导风向，基本风压0.35kN/m2，基本雪压0kN/m2。年降雨量1002.3mm，最大雨量135.6mm/d。 拟建建筑场地已经人工填土平整，地形平坦，地面高程为2.4m。土质构成自地表向下依次为： ①杂填土：厚度约为0.6m，承载力特征值fak=85kPa，天然重度16.2kN/m2。 ②灰色粘土：厚度约为1.8m，承载力特征值fak=120kPa，天然重度18.4kN/m2。 ③褐色粉质粘土：厚度约为1.6m，少量粉砂，含粘粒，饱和，松散稍密状。承载力特征值fak=220kPa，天然重度19.4kN/m2。 ④中砂：厚度约为6.7m，以中粗砂为主，饱和，属密实状态，承载力特征值为240kPa，工程地质性质良好，可作为持力层。 场地地下水水位高程约为2.3m。经取水样进行水质分析，判定该地下水对混凝土无侵蚀性。经地质勘察部门确定，场地地震基本烈度为7度，设计基本地震的加速度为0.1g，框架抗震等级为三级。建筑场地为Ⅱ类，设计地震分组为第三组，场地特征周期为0.45s。梁、板、柱的混凝土均选用C30，梁、柱主筋选用HRB400，箍筋选用HPB300，板受力钢筋选用HRB335。 1.2 建筑设计方案 一个设计应满足到适用、耐久、美观三大要求。首先，应考虑场地的环境、使用功能、结构施工、材料设备、建筑经济及建筑艺术等问题，同时，还应考虑建筑与结构，建筑与各种设备等相关技术的综合协调，以及如何以更少的材料、劳动力、投资和时间来实现各种要求。该工程为多层住宅楼，根据设计任务书的要求，该住宅楼层 m左右。 数为6层，建筑面积47002 1.3 结构设计说明 本工程采用 ，框架抗震等级为三级。本工程耐火等级为二级，其建筑构件的耐火极限及燃烧性能均按民用建筑设计规范执行.全部图纸尺寸除标高以米为单位外均以毫米为单位。本工程结构图中所注标高均为结构标高。
很详细的系统架构图 --专业推荐 2013.11.7 1.1. 共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图，上图整体展现说明包括以下几个方面： 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发，从而建立行业的全面的应用系统架构群。整体应用系统通过SOA 面向服务管理架构模式实现应用组件的有效整合，完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类，具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源，我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源，我们将通过全面的接口管理体系进行相应资源采集模板的搭建，采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现，具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用
最终数据将通过内外网门户对外进行发布，相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询，从而有效提升了我局整体应用服务质量。 综上，我们对本次项目整体逻辑架构进行了有效的构建，下面我们将从技术角度对相 关架构进行描述。 1.2. 技术架构设计 如上图对本次项目整体技术架构进行了设计，从上图我们可以看出，本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。 1.3. 整体架构设计
1.【实验目的】 对称： 通过算法设计并编程实现对给定集合上的关系是否为对称关系的判断，加深学生对关系性质的理解，掌握用矩阵来判断关系性质的方法 自反： 通过算法设计并编程实现对给定集合上的关系是否为自反关系的判断，加深学生对关系性质的理解，掌握用矩阵来判断关系性质的方法。 2.【实验内容】 已知关系R 由关系矩阵M 给出，要求判断由M 表示的这个关系是否为对称关 系。假定R 的关系矩阵为：?????? ? ??=1234210330124321M 3.【实验要求】 C 语言编程实现 4.【算法描述】 对称： 从给定的关系矩阵来判断关系R 是否为对称是很容易的。若M （R 的关系矩阵）为对称矩阵，则R 是对称关系；若M 为反对称矩阵，则R 是反对称关系。因为R 为对称的是等价关系的必要条件，所以，本算法可以作为判等价关系算法的子程序给出。 算法实现： （1） 输入关系矩阵M （M 为n 阶方阵）； （2） 判断对称性，对于i=2，3，….，n ；j=1，2,……，i-1，若存在m ij =m ji ， 则R 是对称的； （3） 判断反对称性； （4） 判断既是对称的又是反对称的； （5） 判断既不是对称的又不是反对称的； （6） 输出判断结果。
自反： 从给定的关系矩阵来断判关系R是否为自反是很容易的。若M（R的关系矩阵）的主对角线元素均为1，则R是自反关系；若M（R的关系矩阵）的主对角线元素均为0，则R是反自反关系；若M（R的关系矩阵）的主对角线元素既有1又有0，则R既不是自反关系也不是反自反关系。本算法可以作为判等价关系算法的子程序给出。 算法实现 （1）输入关系矩阵M（M为n阶方阵）。 （2）判断自反性，对于i=1，2，….，n；若存在m =0，则R不是自反 ii =1，则R是自反的；否则R既不是自反关系也不是的；若存在m ii 反自反关系。 （3）输出判断结果。 源代码 #include
安全生产责任制度 (4) 安全生产培训教育制度 (6) 安全生产会议制度 (8) 安全隐患排查制度 (10) 安全技术措施管理制度 (11) 防护用具使用管理制度 (13) 特种作业人员管理制度 (15) 安全生产委员会安全生产责任制 (16) 企业法人安全生产责任制 (17) 总经理安全生产责任制 (18) 安全生产副总经理安全生产责任制 (19) 总工程师安全生产责任制 (20) 安全部负责人安全生产责任制 (22) 专职安全员安全生产责任制 (24)
安全管理体系
安全生产责任制度 1．企业法定代表人是本企业安全生产工作的第一责任人，依法对本企业的安全生产工作负全面责任；项目经理是项目工程的安全生产工作的第一责任人，对本项目工程的安全施工负责。 2．企业成立“安全生产委员会（领导小组）”，领导和协调企业安全生产工作，明确一名副总经理主管安全生产工作，并设置安全部，配备和派驻专职安全生产管理人员。各项目部建立安全生产管理小组，受企业“安全生产委员会（领导小组）的统一领导（见框图）。 3．安全生产责任制贯彻“一级抓一级、一级对一级负责”的原则，责任到人，形成安全管理体系网络，安全管理目标层层分解落实，公司安全管理目标分解到部门及项目部，项目部分解到管理人员、作业班组，公司对部门及项目部安全生产考核为年度考核，项目部考核为月考核，考核采用打分表形式，由公司和项目部安全生产领导小组分别实施。 4．各工程项目应在建设单位领取施工许可证前，依据《建设工程施工安全生产备案工作程序》办理工程施工安全生产备案手续，在办理建设工程安全生产备案手续时，施工现场的安全设施、临时设施、围挡等安全生产、文明施工设施要符合有关规定的要求，应通过安监机构的勘验。 5．实行施工总承包的建设工程项目，由总承包单位对施工现场的安全生产负总责，分包单位向总承包单位负责，分包合同中应当明确各自的安全生产方面的权利和义务，总承包单位对分包工程的安全生产负连带责任，分包单位应服从总承包单位的安全生产管理，分包单位因不服从管理导致安全生产事故的，由分包单位承担主要责任。 6．根据工程情况公司向项目部派驻专职安全生产管理人员，设置安全生产管理科，工程项目派驻人员比例为：1万平方米以下的工程不少于1名；1万-5万平方米的工程不少于2名；5万平方米以上的大型工地，按专业派驻3名以上专职安全员，组成安全管理科（组），进行安全监督检查，各施工班组应设置兼职安全员。 7．各级领导必须认真贯彻安全生产责任制度，在布置、检查、总结、评比生产时，同时布置、检查、总结、评比安全工作，严格管
美国国防部架构框架（DoDAF）最新进展 摘要：DoDAF是由美国国防部的US Undersecretary of Defense for Business Transformation 工作小组所制定的系统体系结构框架(Architecture Framework,简称AF)。 关键词：DODAFC4ISR美国国防部架构框架 DoDAF是由美国国防部的US Undersecretary of Defense for Business Transformation工作小组所制定的系统体系结构框架(Architecture Framework,简称AF)。其前身是C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance )体系结构框架。近年来，基于DoDAF而发展出来的有：英国国防部提出的MODAF和NAF (NATO Architecture Framework)。 DoDAF的演进 C4ISR AF 1.0 ----于1996年6月推出。 C4ISR AF 2.0 ----于1997年12月推出。 DoDAF 1.0 ----于2003年8月推出，增加其运用范围，不局限C4ISR里，可以应用到所有的任务领域（Mission Area）；同时也推出CADM v1.01。 DoDAF 1.5 ----于2007年4月推出，特别强调以网路为中心(Net-Centric)的概念，在体系结构的描述里体现了网络为中心的概念；也推出CADM v1.5以便储存Net-Centric新概念的描述文件。 DODAF2.0----于2009年5月28日推出。与前几版相比，2.0版主要有以下几点变化：一是体系结构开发过程从以产品为中心转向以数据为中心，主要是提供决策数据；二是三大视图（作战、技术和系统）转变为更为具体的视图。现在的视图有八种，分别是全视图、数据与信息视图、标准视图、能力视图、作战视图、服务视图、系统视图、项目视图；三是描述了数据共享和在联邦环境中获取信息的需求；四是定义和描述了国防部企业体系结构；五是明确和描述了与联邦企业体系结构的关系；六是创建了国防部体系结构框架元模型；七是描述和讨论了面向服务体系结构(SOA)开发的方法。 国防部体系结构框架2.0是以数据为中心，引进了国防部体系结构元模型(Meta-model)的概念，元模型由概念数据模型(Conceptual Data Model)、逻辑数据模型(Logical Data Model)和物理交换规范(Physical Exchange Specification)组成，是构成国防部体系结构框架整体的重要组成部分。元模型取代了国防部体系结构框架以前版本中的核心体系结构数据模型(Core Architecture Data Model)。 2.0版的国防部体系结构框架分为三卷。第一卷的主要内容包括12部分：简介、体系结构的适用性、国防部体系结构各卷和期刊总览、企业体系结构、体系结构规划、客户需求、方法论、体系结构表示方法、国防部体系结构元模型、基于体系结构的分析、国防部体系结构框架的配置管理以及与其他框架的关系。第二卷的主要内容包括：简介、国防部体系结构框架元模型、国防部体系结构框架视图。第三卷的主要内容包括物理交换规范。在2.0版中，共计有49个视图，这些视图并非都是必不可少的，可根据需要来确定哪些视图是必须的。 DODAF2.0中的视图 与前几版相比，2.0版将原来的三大视图（作战、技术和系统）转变为更为具体的视图。现在的视图有八种，分别是全视图、数据与信息视图、标准视图、能力视图、作战视图、服务视图、系统视图、项目视图 All Viewpoint 体系结构描述中许多跨域性（overarching）方面与所有视图有关。全局视
很详细的系统架构图 专业推荐 2013.11.7
1.1.共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图，上图整体展现说明包括以下几个方面： 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发，从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合，完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类，具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源，我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源，我们将通过全面的接口管理体系进行相应资源采集模板的搭建，采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现，具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用 最终数据将通过内外网门户对外进行发布，相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询，从而有效提升了我局整体应用服务质量。 综上，我们对本次项目整体逻辑架构进行了有效的构建，下面我们将从技术角度对相关架
构进行描述。 1.2.技术架构设计 如上图对本次项目整体技术架构进行了设计，从上图我们可以看出，本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。 1.3.整体架构设计 上述两节，我们对共享平台整体逻辑架构以及项目搭建整体技术架构进行了分别的设计说明，通过上述设计，我们对整体项目的架构图进行了归纳如下：
2008年12月24日，美国防部副首席信息官发布了《国防部体系结构框架2.0版草案》，开始征询意见。这是自2007年4月23日颁布《国防部体系结构框架1.5版》的过渡版本之后，首次推出2.0版。该草案定于2008年12月29日至2009年1月22日交由首席信息官执行委员会、国防部体系结构和标准委员会以及相关单位评审，2009年1月23日至2月5日对评审意见进行汇总，2月6日至26日最后定稿，呈交国防部首席信息官批准。国防部体系结构2.0是以数据为中心，引进了国防部体系结构元模型(Meta-model)的概念，元模型由概念数据模型(Conceptual Data Model)、逻辑数据模型(Logical Data Model)和物理交换规范(Physical Exchange Specification)组成，是构成国防部体系结构框架整体的重要组成部分。元模型取代了国防部体系结构框架以前版本中的核心体系结构数据模型(Core Architecture Data Model)。2.0版的国防部体系结构框架分为三卷。第一卷的主要内容包括11部分：简介、体系结构的适用性、国防部体系结构回顾、企业体系结构、客户需求、体系结构规划、方法论、体系结构表示方法、国防部体系结构元模型、基于体系结构的分析、国防部体系结构框架的配置管理以及与其他框架的关系。第二卷的主要内容包括：简介、国防部体系结构框架元模型、《国防部体系结构框架》2.0版视图。第二卷的支持文件的主要内容包括：国防部体系结构框架的模型开发程序、国防部体系结构框架的产品开发问卷分析报告、《国防部体系结构框架》2.0元模型数据词典。第三卷的主要内容包括物理交换规范。在2.0版中，共计有49个视图，这些视图并非都是必不可少的，可根据需要来确定哪些视图是必须的。 描述了美国国防部（DoD）体系架构（DoDAF）的系统视图（System View，SV）和技术标准视图（Technical Standard View，TV）产品。第一部分文章介绍了DoDAF 概述并描述了运作视图（Ope rational View，OV）产品。 这几篇文章讨论了以遵从美国国防部（DoD）体系架构（DoDAF）的方式为复杂系统架构建模的方法。它们阐述了如何利用建模最佳实践连同统一建模语言（Unified Modeling Language，UML）和IBM Rational 工具来创建不但遵从DoDAF，而且在不转移主要系统开发目标的投入精力的情况下增加复杂系统的设计和开发中的重要价值的模型视图。 在第1 部分文章中，我介绍了DoDAF 规范的概述，并探究了其运作视图（OV）产品。这是对要比较备选系统架构，并管理其开发的政府机构和其他运作决策者最有意义的产品。 在此第2 部分，我将说明系统视图（SV）产品。这是与DoD 承包商和其他设计并实现这些复杂系统架构的人最相关的模型视图。为了完整地了解DoDAF 规范，我还将在第2 部分中简要介绍技术标准视图（TV）产品。 系统视图产品 包含运作架构的系统必须协作，用以实现运作视图中指定的任务功能，这些我在第1 部分文章中提到了。系统视图（SV）产品的用途是提供在考虑中的系统的多种透视图。这些视图描述了系统的结构并表明如何与企业架构的其他要素相互作用。 各种SV 产品是从主题系统架构的白盒扩展得来的，这确定了为了达到所期望的行为必须相互作用的系统的逻辑和物理组件。这些系统（逻辑组件）和系统节点（物理组件）是原型的类，并且由系统环境图表示。这些要素之间的关系表现出创建SV-10c 序列图（见下）时所指定的运作或请求消息。其他SV 产品提供更多关于物理和逻辑系统接口、系统交互，和在运作企业环境下系统的有计划的演进。
安全生产责任制度 (3) 安全生产培训教育制度 (4) 安全生产会议制度 (5) 安全隐患排查制度 (6) 安全技术措施管理制度 (7) 防护用具使用管理制度 (8) 特种作业人员管理制度 (9) 安全生产委员会安全生产责任制 (10) 企业法人安全生产责任制 (11) 总经理安全生产责任制 (12) 安全生产副总经理安全生产责任制 (13) 总工程师安全生产责任制 (14) 安全部负责人安全生产责任制 (15) 专职安全员安全生产责任制 (16)
安全管理体系
安全生产责任制度 企业法定代表人就是本企业安全生产工作得第一责任人,依法对本企业得安全生产工作负全面责任;项目经理就是项目工程得安全生产工作得第一责任人,对本项目工程得安全施工负责。 企业成立“安全生产委员会(领导小组)”,领导与协调企业安全生产工作,明确一名副总经理主管安全生产工作,并设置安全部,配备与派驻专职安全生产管理人员。各项目部建立安全生产管理小组,受企业“安全生产委员会(领导小组)得统一领导(见框图)。 实行施工总承包得建设工程项目,由总承包单位对施工现场得安全生产负总责,分包单位向总承包单位负责,分包合同中应当明确各自得安全生产方面得权利与义务,总承包单位对分包工程得安全生产负连带责任,分包单位应服从总承包单位得安全生产管理,分包单位因不服从管理导致安全生产事故得,由分包单位承担主要责任。 根据工程情况公司向项目部派驻专职安全生产管理人员,设置安全生产管理科,工程项目派驻人员比例为:1万平方米以下得工程不少于1名;1万-5万平方米得工程不少于2名;5万平方米以上得大型工地,按专业派驻3名以上专职安全员,组成安全管理科(组),进行安全监督检查,各施工班组应设置兼职安全员。 各级领导必须认真贯彻安全生产责任制度,在布置、检查、总结、评比生产时,同时布置、检查、总结、评比安全工作,严格管理,促进安全生产工作不断发展。 6．各级工会组织与全体职工,有权监督各级各部门对本制度得贯彻执行情况。
第一章 1.软件复用：利用现有的软件资源来开发新应用系统的过程。其中软件资源可能是已经存在的软件，也可能是专门用于开发设计且可复用的软件构件。 2.可复用的软件的资源即复用成分，是软件服用技术的核心与基础。 3.实现软件复用需要解决三个问题： 1.有可以复用的对象 2.所复用的对象的对象是可用的 3.复用者要知道怎样去使用被复用的对象 4..软件重用再工程五个阶段： （1）候选阶段（2）选择阶段（3）资格说明阶段（4）分类和存储阶段（5）查找和检索5.软件复用： （1）代码复用分为目标代码复用和源代码复用 （2）设计复用比源程序复用的级别更高 （3）分析复用要比设计复用的级别更高 （4）测试复用主要包括测试用例复用和测试过程复用 6.软件复用的实现技术：组装和生成 在组装中软件构件是复用的基石 在生成中由程序生成器完成对软件结构模式的复用 7.从构件的表示角度出发，分为人工智能方法、超文本和信息科学方法 信息科学方法：枚举层次关键词分类方法 8.软件构件化：就是要让软件开发过程向机械加工一样，可以使用各种标准的和非标准的零件来组装机器。 9.抽象构件模型：提供服务接口--（软件构件：属性集合行为集合）--接收服务接口 10.网络服务技术：OMG的CORBA;SUN公司的J2EE/JavaBeans/EJB;Microsoft的DCOM/COM/COM+ 11.构件获取的四种方式： （1）从构件库中，按照适合新系统的原则选取，并做适应性修改已获得可重用的构件。（2）根据新功能模块进行自行开发，以获取新构件 （3）对遗留系统进行功能分析，将具有潜在应用价值的模块提取出来，使其接口进行标准化以获得可重用性构件 （4）通过商业方式购买合适的构件，利用互联网资源进行共享或免费获取 12.框架：是一种为特定领域应用提供可扩展模版的架构实例。它表述了整个设计过程、指明了协作对象之间的依赖关系、明确了责任分配和控制流 13.软件体系结构主要包括：构件、连接件和配置约束 14.构件：可预制和可重用的软件部件，是组成体系结构的基本计算单元或数据存储单元
很详细的系统架构图--专业推荐 2013.11.7
1.1.共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图，上图整体展现说明包括以下几个方面： 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发，从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合，完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类，具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源，我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源，我们将通过全面的接口管理体系进行相应资源采集模板的搭建，采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现，具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用 最终数据将通过内外网门户对外进行发布，相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询，从而有效提升了我局整体应用服务质量。 综上，我们对本次项目整体逻辑架构进行了有效的构建，下面我们将从技术角度对相
关架构进行描述。 1.2.技术架构设计 如上图对本次项目整体技术架构进行了设计，从上图我们可以看出，本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。 1.3.整体架构设计 上述两节，我们对共享平台整体逻辑架构以及项目搭建整体技术架构进行了分别的设计说明，通过上述设计，我们对整体项目的架构图进行了归纳如下：
1、框架结构体系的特点 1．1建筑平面布置灵活，使用空间大。 1．2延性较好。 1．3整体侧向刚度较小，水平力作用下侧向变形较大（呈剪切型）。所以建筑高度受到限制。 1．4非结构构件破坏比较严重。 2、框架结构体系选择的因素及适用范围 2．1考虑建筑功能的要求。例如多层建筑空间大、平面布置灵活时。 2．2考虑建筑高度和高宽比、抗震设防类别、抗震设防烈度、场地条件等因素。 框架结构体系是介于砌体结构与框架-剪力墙结构之间的可选结构体系。框架结构设计应符合安全适用、技术先进、经济合理、方便施工的原则（结构设计原则）。 非抗震设计时用于多层及高层建筑。抗震设计时一般情况下框架结构多用多层及小高层建筑（7度区以下）。 框架结构由于其抗侧刚度较差，因此在地震区不宜设计较高的框架结构。在7度（）设防区，对于一般民用建筑，层数不宜超过7层，总高度不宜超过28米。在8度（）设防区，层数不宜超过5层，总高度不宜超过20米。超过以上数据时虽然计算指标均满足规范要求，但是不经济。 3、结构平面、竖向布置 3．1为了保证框架结构的抗震安全，结构应具有必要的承载力、刚度、稳定性、延性及耗能等性能。设计中应合理地布置抗侧力构件，减少地震作用下的扭转效应；平面布置宜规则、对称，并应具有良好的整体性；结构的侧向刚度宜均匀变化，竖向抗侧力构件的截面尺寸和材料强度宜自下而上逐渐减小（不应在同一层同时改变构件的截面尺寸和材料强度），避免抗侧力结构的侧向刚度和承载力突变。 3．2框架结构宜设计成双向梁柱刚架体系以承受纵横两个方向的地震作用或风荷载。特殊情况下也可以采用一向为刚架，另一向为铰接排架的结构体系。但在铰接排架方向应设置支撑或抗震墙，以保证结构的承载力、刚度和稳定。 3．3抗震设计的框架结构，不宜采用单跨框架。如果不可避免的话，可设计为框架-剪力墙结构，多层建筑也可仅在单跨方向设置剪力墙。后者框架结构部分的抗震等级应按框架结构选用，而剪力墙部分的抗震等级应按框架-剪力墙结构选用。
一、已知A、B、C是三个集合，证明(A∪B)－C＝(A－C)∪(B－C) 证明：因为 x∈(A∪B)－C?x∈(A∪B)－C ?x∈(A∪B)∧x?C ?(x∈A∨x∈B)∧x?C ?(x∈A∧x?C)∨(x∈B∧x?C) ?x∈(A－C)∨x∈(B－C) ?x∈(A－C)∪(B－C) 所以，(A∪B)－C＝(A－C)∪(B－C)。 二、设R={<2，1>，<2，5>，<2，4>，<3，4>，<4，4>，<5，2>}，求r(R)、s(R)和t(R)，并作出它们及R的关系图。 解：r(R)={<2，1>，<2，5>，<2，4>，<3，4>，<4，4>，<5，2>，<1，1>，<2，2>，<3，3>，<4，4>，<5，5>} s(R)={<2，1>，<2，5>，<2，4>，<3，4>，<4，4>，<5，2>，<1，2>，<4，2>，<4，3>} R2=R5={<2，2>，<2，4>，<3，4>，<4，4>，<5，1>，<5，5>，<5，4>} R3={<2，1>，<2，5>，<2，4>，<3，4>，<4，4>，<5，2>，<5，4>} R4={<2，2>，<2，4>，<3，4>，<4，4>，<5，1>，<5，5>，<5，4>} t(R)={<2，1>，<2，5>，<2，4>，<3，4>，<4，4>，<5，2>，<2，2>，<5，1>，<5，4>， <5，5>} 三、证明等价关系 设R是集合A上的一个具有传递和自反性质的关系，T是A上的关系，使得
常用的系统架构图 2014年冬
1.1.共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图，上图整体展现说明包括以下几个方面： 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发，从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合，完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类，具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源，我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源，我们将通过全面的接口管理体系进行相应资源采集模板的搭建，采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现，具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用 最终数据将通过内外网门户对外进行发布，相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询，从而有效提升了我局整体应用服务质量。 综上，我们对本次项目整体逻辑架构进行了有效的构建，下面我们将从技术角度对相
关架构进行描述。 1.2.技术架构设计 如上图对本次项目整体技术架构进行了设计，从上图我们可以看出，本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。 1.3.整体架构设计 上述两节，我们对共享平台整体逻辑架构以及项目搭建整体技术架构进行了分别的设计说明，通过上述设计，我们对整体项目的架构图进行了归纳如下：
软件体系结构
目录 第一章软件体系结构概述 (3) 1.软件体系结构定义 (3) 2.软件体系结构内容 (3) 3.UML (4) 4.抽象、接口、高内聚、低耦合常用概念 (4)
第一章软件体系结构概述 1.软件体系结构定义 Architecture Styles，定义为根据结构组织模式构成的软件系统族，表达了部件和他们之间的关系。例如客户/服务器（Client /Server）结构、浏览器/服务器（Browser/Server）结构等。 2.软件体系结构内容 1.体系结构风格（Architecture Styles） 体系结构风格是描述特定系统组织方式的惯用范例，强调组织模式和惯用范例。组织模式即静态表述的样例，惯用范例则是反映众多系统共有的结构和语义。通常，体系结构风格独立于实际问题，强调了软件系统中通用的组织结构，比如管道线，分层系统，客户机-服务器等等。体系结构风格以这些组织结构定义了一类系统族。 2. 设计模式（Design Pattern） 设计模式是软件问题高效和成熟的设计模板，模板包含了固有问题的解决方案。设计模式可以看成规范了的小粒度的结构成分，并且独立于编程语言或编程范例。设计模式的应用对软件系统的基础结构没有什么影响，但可能对子系统的组织结构有较大影响。每个模式处理系统设计或实现中一种特殊的重复出现的问题。例如，工厂模式，它为解决抽象部分和实现部分独立变化的问题提供了一种通用结构。因此，设计模式更强调直接复用的程序结构。 3. 应用框架（Application Framework） 应用框架是整个或部分系统的可重用设计，表现为一组抽象构件的集合以及构件实例间交互的方法。可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法，它为构
《软件体系结构》期 末复习题
《软件体系结构》期末复习题 简答题： 1、软件体系结构建模的种类有： 结构模型、框架模型、动态模型、过程模型、功能模型。 2、“4+1”视图模型从5个不同的视角包括： 逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。 3、构件：是具有某种功能的可重用的软件模板单元，表示了系统中主要的计算元素和数据存储。 连接件：表示构件之间的交互。 配置：表示构件和连接件的拓扑逻辑和约束。 端口：表示构件和外部环境的交互点。 角色：定义了该连接交互的参与者。 4、画出“4+1”视图模型图，分析各部分的原理和功能。 5、软件体系结构风格： 是描述某一特定应用领域中系统组织方式的惯用模式。 6、软件体系结构 （Software Architecture）
软件体系结构以组件和组件交互的方式定义系统，说明需求与成品系统之间的对应关系，描述系统级别的可伸缩性、能力、吞吐量、一致性和兼容性等属性。软件体系结构由组件、连接件和属性组成。 7、分层系统的优点有： 1）支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解； 2）支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层； 3）支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。 8、分层系统的缺点有： 1）并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来； 2）很难找到一个合适的、正确的层次抽象方法。 9、 B/S体系结构的优点有什么？ 答：1）基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。 2）B/S体系结构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。 10、B/S体系结构的缺点有什么？ 答：1）B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。 2）B/S体系结构的系统扩展能力差，安全性难以控制。