DoD Architecture Framework Version 1.0, Volume 2 - AcqNotes.com

More documents

Recommendations

Info

5.5.2 UML RepresentationThere is no equivalent for this product in UML. However, the information for an SV-5matrix may be gathered from OV-5 and SV-4 element adornments (e.g., relationships between OV-5 use cases and SV-4 use cases). A UML modeling tool script may beused to extract the underlying architecture data and convert it to matrix form.Since SV-4 use cases are refinements of OV-5 use cases, the relationship between theoperational activities and associated capabilities on the OV side, and the system functions on theSV side, is already defined. System functions can also be allocated to systems in UML byallocating SV-4 classes and packages to UML Components (from SV-1) ac<strong>com</strong>plishing theintent of SV-5.5.5.3 Operational Activity to Systems Function Traceability Matrix (SV-5) – DataElement DefinitionsTable 5-5 describes the architecture data elements for SV-5.Table 5-5. Data Element Definitions for Operational Activity to Systems Function Traceability Matrix (SV-5)Data Elements Attributes Example Values/ExplanationReferenced TypesCapabilitySee OV -5 Definition TableSystemSee SV -1 Definition TableOperational Activity*See OV -5 Definition TableSystem Function*See SV -4 Definition TableRelationshipsSystem Function of aSystem SupportsOperational Activity for aCapabilitySystem Function Name Name/identifier of system functionOperational ActivityNameName/identifier of an operational activity that is associatedwith the capability and supported by the system functionSystem NameName/identifier of system that executes the systemfunctionCapability NameName/identifier of a capability associated with theoperational activity and supported by the systemSupport Status Code One of: red, yellow, or green. Red means functionalityplanned but not developed; yellow means partialfunctionality provided or full functionality provided butsystem has not been fielded; and green means fullfunctionality provided and system has been fieldedSystem FunctionImplements OperationalActivity*System Function Name*Operational ActivityName*Name/identifier of system functionName/identifier of operational activity (at least partially)implemented by the system function5.5.4 CADM Support for Operational Activity to Systems Function TraceabilityMatrix (SV-5)SV-5 is stored as an instance of DOCUMENT with a category code designating it as aSYSTEM-FUNCTION-TRACEABILITY-MATRIX (a subtype of DOCUMENT). The properties of eachcell of the SYSTEM-FUNCTION-TRACEABILITY-MATRIX are specified using SYSTEM-FUNCTION-TRACEABILITY-MATRIX-ELEMENT.5-38
A SYSTEM -FUNCTION-TRACEABILITY-MATRIX can apply to many architectures. All theARCHITECTURE instances to which that DOCUMENT applies are specified in ARCHITECTURE-DOCUMENT.Each function cited in the SYSTEM -FUNCTION-TRACEABILITY-MATRIX is stored as aninstance of PROCESS-ACTIVITY with a category code designating it as a SYSTEM-FUNCTION (asubtype of PROCESS-ACTIVITY).SYSTEM-PROCESS-ACTIVITY identifies all the SYSTEM -FUNCTION instances and otherPROCESS-ACTIVITY instances that are associated with a specific SYSTEM. Each such associationis provided one of the following type codes: 1 = Is designed to carry out; 2 = Performs (i.e., hasa function represented by); 3 = Provides partial support for; or 4 = Provides an alternatecapability for.A key element of operational requirement traceability is the relation of SYSTEM -FUNCTION instances and other PROCESS-ACTIVITY instances to TASK instances. This traceabilityis provided by populating PROCESS-ACTIVITY-TASK.The CADM provides two levels of association of System Functions to OperationalActivities. The first is independent of architecture and architecture product and thus appliesglobally in all situations. This global level of association is stored as instances of PROCESS-ACTIVITY-ASSOCIATION and can be designated by a code in this entity as the following kind ofassociation: Is derived from; Is identical to; Is part of; Directly supports; and Indirectlysupports (additional types of association can be defined and agreed to by modifying the valuesfor PROCESS-ACTIVITY-ASSOCIATION Role Code). Ideally, the global level of association ofSystem Functions to Operational Activities can be specified as System Functions or OperationalActivities are defined (whichever <strong>com</strong>es second). At a minimum, the global association wouldaddress specific Operational Activities that would not be supported if no system providing theSystem Functions is fielded.The second level of association can be specific to an architecture and its architectureproduct(s). This architecture-level association is stored as instances of SYSTEM -FUNCTION-TRACEABILITY-MATRIX-ELEMENT. At present, the architecture-level association is weak in thatit only establishes an association but does not categorize it (in contrast to the global level ofassociation).Each row of the SYSTEM -FUNCTION-TRACEABILITY-MATRIX-ELEMENT has all theproperties of the following entities that are directly referenced (by foreign key attributes) in thisentity:• Operational PROCESS-ACTIVITY• SYSTEM• System PROCESS-ACTIVITY• SYSTEM-PROCESS-ACTIVITY• TASKFigure 5-24 provides a high-level diagram from the CADM showing key entities that areused to store architecture data for SV-5 in a CADM-conformant database.5-39
Page 2 and 3:
SECTIONTABLE OF CONTENTSPAGE1 INTRO
Page 4 and 5:
SECTIONTABLE OF CONTENTS (Cont)PAGE
Page 6 and 7:
Page 8 and 9:
Page 10 and 11:
SECTIONANNEXTABLE OF CONTENTS (Cont
Page 12 and 13:
FIGURELIST OF FIGURES (Cont)PAGE4-1
Page 14 and 15:
FIGURELIST OF FIGURES (Cont)PAGE5-3
Page 16 and 17:
TABLELIST OF TABLES (Cont)PAGE5-13
Page 18 and 19:
Hereafter in this document, the ter
Page 20 and 21:
architecture that should be capture
Page 22:
2.1.2 Definition of the Systems Vie
Page 25 and 26:
The following legend is used in the
Page 27 and 28:
2.3 ARCHITECTURE DATA ELEMENTSAs st
Page 29 and 30:
Within each perspective, all produc
Page 31:
software systems, as well as for bu
Page 34 and 35:
Figure 2-5. CADM Distinctions for A
Page 36 and 37:
Tools and File Formats Used identif
Page 38 and 39:
Data Elements Attributes Example V
Page 40 and 41:
Data Elements Attributes Example V
Page 42 and 43:
• TASK and ARCHITECTURE-TASK (whi
Page 44 and 45:
3.2.2 TaxonomiesAV-2 defines the ar
Page 46 and 47:
TAXONOMY TYPES STRUCTURE AVOperatio
Page 48 and 49:
Taxonomies relate two instances, of
Page 50 and 51:
• INFORMATION-ELEMENT-DOCUMENT•
Page 52 and 53:
geographical distribution of assets
Page 54 and 55:
Data Elements Attributes Example Va
Page 56 and 57:
Figure 4-3. CADM ER Diagram for Hig
Page 58 and 59:
and their attributes (such as perio
Page 60 and 61:
GenericSubscriber NodeRequiringServ
Page 62 and 63:
Hierarchy ChartConnectorReferenced
Page 64 and 65:
• Information content of IERs (or
Page 66 and 67:
4.3 OPERATIONAL INFORMATION EXCHANG
Page 68 and 69:
4.3.2 UML RepresentationThere is no
Page 70 and 71:
DataElementsInformationExchange has
Page 72 and 73:
• INFORMATION-EXCHANGE-REQUIREMEN
Page 74 and 75:
AGREEMENT IDENTIFIER in INFORMATION
Page 76 and 77:
Figure 4-10. CADM ER Diagram for Op
Page 78 and 79:
WorkingGroupTop-LevelOrganizationCo
Page 80 and 81:
4.4.4 CADM Support for Organization
Page 82 and 83:
OV-5 is a key product for describin
Page 84 and 85:
Flow 1$A1Activity 1Node ANode CFlow
Page 86 and 87:
ExternalSourceNode ANode BNode CNod
Page 88 and 89:
Page 90 and 91:
Page 92 and 93:
Page 94 and 95:
Threads of activities are specified
Page 96 and 97:
• Action Assertions: These rules
Page 98 and 99:
Table 4-6. Data Element Definitions
Page 100 and 101:
model element. Behavior is modeled
Page 102 and 103:
Processes receiving multiple inputs
Page 104 and 105: Data Elements Attributes Example Va
Page 106 and 107: of the activities, and includes the
Page 108 and 109: Precedence linkindicatesorder betwe
Page 112 and 113: 4.7 LOGICAL DATA MODEL (OV-7)4.7.1
Page 114 and 115: 4.7.3 Logical Data Model (OV-7) - D
Page 116 and 117: DATA-DOMAIN (all subtypes of INFORM
Page 118 and 119: nodes. The term system in the frame
Page 120 and 121: second, logically distinct interfac
Page 122 and 123: Interface 1Node ASystem 1Node BSyst
Page 126 and 127: • ORGANIZATION-TYPE-ESTABLISHMENT
Page 128 and 129: 5.2 SYSTEMS COMMUNICATIONS DESCRIPT
Page 130 and 131: SV-2 intranodal perspective may be
Page 134 and 135: • NETWORK-DETAIL• NETWORK-NODE
Page 136 and 137: Figure 5-11. CADM ER Diagram for Sy
Page 138 and 139: 5.3.2 UML RepresentationThere is no
Page 142 and 143: FUNCTION 1SUBFUNCTION11SUBFUNCTION1
Page 144 and 145: The systems use cases and classes a
Page 148 and 149: used to identify an external source
Page 152 and 153: Operational ActivitiesSystem Functi
Page 156 and 157: Figure 5-24. CADM ER Diagram for Op
Page 158 and 159: InterfaceIdentifierDataExchangeIden
Page 162 and 163: Using these references, all the att
Page 166 and 167: System NameHardware Element 1Mainta
Page 168 and 169: Data Elements Attributes Example va
Page 170 and 171: 5.8 SYSTEMS EVOLUTION DESCRIPTION (
Page 176 and 177: A template for SV-9 is shown in Tab
Page 184 and 185: Because the structural assertion ru
Page 188 and 189: terms of triggers or events (genera
Page 192 and 193: Table 5-14. Data Element Definition
Page 194 and 195: 5.11 PHYSICAL SCHEMA (SV-11)5.11.1
Page 196 and 197: Object classes defined here should
Page 198 and 199: Figure 5-42. CADM ER Diagram for Ph
Page 200 and 201: documents are used, then the relati
Page 202 and 203: Table 6-2. TV-1 Template with Corre
Page 204 and 205:
Table 6-4. Data Element Definitions
Page 206 and 207:
Page 208 and 209:
Figure 6-3. INFORMATION-TECHNOLOGY-
Page 210 and 211:
Figure 6-5 provides a high-level di
Page 212 and 213:
6.2 TECHNICAL STANDARDS FORECAST (T
Page 214 and 215:
Page 216 and 217:
7 FRAMEWORK ARCHITECTURE DATA ELEME
Page 218 and 219:
• The Technical Standards Profile
Page 220 and 221:
• Events in the Operational State
Page 222 and 223:
• Rules in the Systems Rules Mode
Page 224 and 225:
7.6 SUMMARY OF ARCHITECTURE DATA EL
Page 226 and 227:
LINK TO… BY:SV-4 System data flow
Page 228 and 229:
ANNEX AGLOSSARYA&IA&TACCACLAFWGAMSA
Page 230 and 231:
FIPSFNAFOCFoSFPIFRPFSAGCCSGIGGUIHCI
Page 232 and 233:
OAOASDOIEMOMBOMGONCDOOOPLANOSDOVPMP
Page 234 and 235:
ANNEX BDICTIONARY OF TERMSThe terms
Page 236 and 237:
Initial CapabilitiesDocumentIntegra
Page 238 and 239:
SystemSystem Data ElementAny organi
Page 240 and 241:
AssociationAttributeBuildingBlocksC
Page 242 and 243:
NotesObjectObject DiagramOperations
Page 244 and 245:
Use Case Model A model that describ
Page 246 and 247:
COST-BASISCOUNTRYDATA-ITEM-TYPEDECI
Page 248 and 249:
NETWORK-TYPENODEMODELING-AND-SIMULA
Page 250 and 251:
INTERFACE-TYPETECHNICAL-SERVICETECH
Page 252 and 253:
[DEB, 2000][DeMarco, 1979][Departme
Page 254:
[OMG, 2000][OMG, 2001][Rumbaugh, 19
show all

DoD Architecture Framework Version 1.0, Volume 2 - AcqNotes.com

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?