“The Systems Interface Description depicts systems nodes and the systems resident at these nodes to support organizations/human roles represented by operational nodes of the Operational Node Connectivity Description (OV-2). SV-1 also identifies the interfaces between systems and systems nodes. OV-2 depicts the operational nodes representing organizations, organization types, and/or human roles, while SV-1 depicts the systems nodes that house operational nodes (e.g., platforms, units, facilities, and locations) and the corresponding systems resident at these systems nodes and which support the operational nodes. In addition to depicting systems nodes and systems, SV-1 addresses system interfaces. An interface, as depicted in SV-1, is a simplified, abstract representation of one or more communications paths between systems nodes or between systems.” [DoDAF, v1.0, Vol. II]
SV-1 is a diagram, which is based on either UML Class Diagram or UML Composite Structure Diagram depending on the level of details.
User also may use:
Regular UML Class Diagram
Regular UML Composite Structure Diagram
UML Implementation Diagram
SysML Block Definition Diagram
SysML Internal Block Diagram
Any other MagicDraw diagram
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
System |
<<System>> [Class] |
|
Systems Node |
<<SystemsNode>> [Class] |
|
Interface |
<<Interface>> [Association, Connector] |
N/A |
System Usage |
<<SystemUsage>> [Property] |
|
Systems Node Usage |
<<SystemsNodeUsage>> [Property] |
|
Hardware/Software Item |
<<Hardware/SoftwareItem>> [Class] |
|
Organizational Resource Usage |
See OV-2 data element definitions |
|
Operational Node |
See OV-2 data element definitions |
|
Needline |
See OV-2 data element definitions |
|
ServiceSpecification |
See OV-2 data element definitions |
|
SoaService |
See OV-2 data element definitions |
|
Interface Implementer |
See SV-2 data element definitions |
|
System Function |
See SV-4 data element definitions |
|
System Data Exchange |
See SV-6 data element definitions |
|
System Data Element |
See SV-6 data element definitions |
Any organized assembly of resources and procedures united and regulated by interaction or interdependence to accomplish a set of specific functions. A term system in the framework is used to denote a family of systems (FoS), system of systems (SoS), nomenclature system, or a subsystem.
Derives from SysML Block, extends UML Class.
participant: Participant |
Defines participant role that is applied to System. Possible values are taken from Participant enumeration: System Service Provider System Service Consumer |
performedFunctions: SystemFunction [*] |
System functions performed by system |
performanceParameterSet: PerformanceParameterSet [*] |
Performance Parameter Sets specified for System |
measurements: PerformanceMeasurementSet [*] |
A list of Performance Measured Sets with measured Performance Parameter Set values |
A node with the identification and allocation of resources (e.g., platforms, units, facilities, and locations) required implementing specific roles and missions. Usually denotes a facility where an Operational Node is located.
Derives from SysML Block, extends UML Class.
implements: OperationalNode [*] |
Operational Nodes housed by Systems Node |
allocatedFunctions: SystemFunction [*] |
System Functions allocated at Systems Node |
An interface is the abstract representation of
one or more Communication Paths between
Systems Nodes or between Systems. An SV-1 Interface is the systems representation
of OV-2 Needline.
Extends UML Association (in block definition diagrams), UML Connector (in internal block diagrams)
supportedNeedline: Needline [1] |
Needline depicted by Interface |
implementedBy: InterfaceImplementer [*] |
A set of Communications Links and Communications Paths that implement Interface |
System Usage is a helper element that is needed to show a System inside other System. We are using SysML based approach here: parent System will have a System Usage as a SysML BlockProperty. The type of the System Usage will be child Systems Node.
Derives from SysML BlockProperty (extends Property).
Note. This is the same as Part in UML composite structure diagrams.
participant: Participant |
Defines participant role that is applied to System Usage. Possible values are taken from Participant enumeration: System Service Provider System Service Consumer |
This is a helper element similar to System Usage.
Derives from SysML BlockProperty (extends Property).
Note. This is the same as Part in UML composite structure diagrams.
Organizational Resource Usage is a helper element that is needed to show an Organizational Resource inside System or Systems Node. We are using SysML based approach here; The parent System or Systems Node will have a Organizational Resource Usage described as a SysML BlockProperty.
Derives from SysML BlockProperty (extends Property).
Note. This is the same as Part in UML composite structure diagrams.
Describes the Software and/or hardware items of a system (or subsystem). Represents a software application or hardware equipment that has a serial number (or other identifier).
Derives from System.
vendors/source: String |
Source of system Software or Hardware Item |
Figure 23 SV-1 profile diagram
It is recommended at first to create the SV-1 Systems Interface Descriptions with main Systems and System Nodes.
If you have composite structure for the Systems or System Nodes, you need to create an SV-1 Systems Internal Interface Description for the Systems/System Nodes that have sub-elements. Sub-elements will be created as System Usages and Systems Node Usages in the parent System/Systems Node. Child elements will be set as type for the Operational Node Usages.
Node’s internal diagram can be easily created from a System/Systems Node (context menu -> New Diagram -> SV-1 Systems Internal Interface Description).
Modeling service architectures
SV-1 product may be used for modeling service architectures. System and sub systems (System Usages) have “Participant” property that allows you to specify the responsibility System plays: System Service Consumer or System Service Provider.
System Service Consumer and System Service Provider can communicate only via Soa Service. Since Soa Service extends UML Port System Service Provider and System Service Consumer should be realizing classifiers of the same component. To model this on SV-1 Systems Interface Description diagram create Component and drag on it Systems. Systems will become realizing classifiers of the same Component and you will be able to connect their Soa Services using Interface [connector] relationship.
The type of Soa Service can be UML Interface or Service Specification. Use Service Specification when there is behavior for using Soa Service. After behavior addition you may detail it using any type of behavior diagram. After this double-click on Service Specification will open not Service Specification specification dialog but associated behavior diagram.
Systems Node may realize the Operational Node from OV-2 (property realizes).
Systems Node may show allocated System Functions from SV-4 (property allocatedFunctions)
Interface may carry System Data Exchanges from SV-6 (property dataExchange).
Interface may support Needline from OV-2 (property supportedNeedline).
System and Hardware/Software Items may show performed System Functions (property performedFunctions)
Interface may show implementing Communication Links (property implementedBy)
Figure 24 SV-1 sample (Systems Nodes)
Figure 25 SV-1 sample (Systems)
Figure 26 SV-1 sample (Systems Node internal)
“The Systems Communications Description depicts pertinent information about communications systems, communications links, and communications networks. SV-2 documents the kinds of communications media that support the systems and implement their interfaces as described in SV-1. Thus, SV-2 shows the communications details of SV-1 interfaces that automate aspects of the Needlines represented in OV-2.” [DoDAF, v1.0, Vol. II]
SV-2 is a diagram, which is based on either UML Class Diagram or UML Composite Structure Diagram depending on the level of details.
User also may use:
Regular UML Class Diagram
Regular UML Composite Structure Diagram
UML Implementation Diagram
SysML Block Definition Diagram
SysML Internal Block Diagram
Any other MagicDraw diagram
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
Interface Implementer |
<<InterfaceImplementer>> [Element] |
N/A |
Communications System |
<<CommunicationsSystem>> [Class] |
|
Communications Link |
<<CommunicationsLink>> [Association, Connector] |
N/A |
Communications Path |
<<CommunicationsPath>> [Class] |
|
Communications Network |
<<CommunicationsNetwork>> [Class] |
|
LAN |
<<LAN>> [Class] |
|
WAN |
<<WAN>> [Class] |
|
MAN |
<<MAN>> [Class] |
|
Interface |
See SV-1 data element definitions |
|
System Usage |
See SV-1 data element definitions |
This is an abstract stereotype that is a parent for Communications Link and Communications Path elements. Only elements derived from Interface Implementer are capable to implement Interface.
Extends UML Element.
Implements: Interface [0..1] |
Interface implemented by Interface Implementer |
A Communications System is a System whose primary function is to control the transfer and movement of system data as opposed to performing mission application processing. Examples include switches, routers, and communications satellites.
Derives from System.
A single physical connection from one System (or Systems Node) to another.
Derives from InterfaceImplementer, extends UML Association (in block definition diagrams), UML Connector (in internal block diagrams
capacity: String |
Channel capacity |
infrastructureTechnology: String |
Infrastructure technology supporting Communications Link |
communicationPath: CommunicationsPath [*] |
Communications Path containing Communications Link |
performanceParameterSet: PerformanceParameterSet [*] |
Performance Parameter Set specified for Communications Link |
measurements: PerformanceMeasurementSet [*] |
A list of Performance Measured Sets with measured Performance Parameter Set values |
A (connected) sequence of Communications Systems and Communications Links originating from one System (or Systems Node) and terminating at another System (or Systems Node).
Communications Path will contain an ordered list of Communications Links.
Derives from InterfaceImplementer, extends UML Class.
communicationLinks: CommunicationsLink [1..*] |
Communications Links contained by Communications Path |
Communications Network is a set of Systems and Communications Links.
Derives from System.
securityClassification: String |
Classification of System Data that Communications Network is allowed to carry |
A subtype of Communications Network defining local area network (LAN).
Derived from CommunicationsNetwork.
A subtype of Communications Network defining wide area network (WAN).
Derived from CommunicationsNetwork.
A subtype of Communications Network defining metropolitan area network (MAN).
Derived from CommunicationsNetwork.
Figure 27 SV-2 profile diagram
Creation of SV-2 is very similar to SV-1.
SV-2 is a refinement of SV-1 that shows how Interfaces are implemented with actual Communication Links. So most of the System elements have to be created to this point. In MagicDraw simply drag those elements from the Data Browser to the SV-2 diagram.
Interfaces from SV-1 are implemented by Communication Links in SV-2 (property implements).
Figure 28 SV-2 sample
“The Systems-Systems Matrix provides detail on the interface characteristics described in SV-1 for the architecture, arranged in matrix form. It allows a quick overview of all interface characteristics presented in multiple SV-1 diagrams. The matrix form can support a rapid assessment of potential commonalities and redundancies (or, if fault-tolerance is desired, the lack of redundancies).
SV-3 is similar to an N2-type matrix, where the systems are listed in the rows and columns of the matrix, and each cell indicates a system pair interface, if one exists.” [DoDAF, v1.0, Vol. II]
SV-3 is a matrix based on dependency matrix in MagicDraw.
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
System |
See SV-1 data element definition |
|
Interface |
See SV-1 data element definition |
Figure 29 SV-3 profile diagram
When user will create SV-3 in the row scope he will be provided with a scope selection (root package by default) for the SV-3. MagicDraw will find all Systems in the given scope will put them as column and row elements. The matrix cells will be filled according to the interfaces between the Systems.
SV-3 uses Systems and Interfaces from SV-1 and SV-2.
Figure 30 SV-3 sample
”SV-4 describes system functions and the flow of system data among system functions. It is the SV counterpart to OV-5. The scope of this product may be enterprise wide, without regard to which systems perform which functions, or it may be system specific. Variations may focus on intra-nodal system data flow, inter-nodal system data flow, and system data flow without node considerations, function to system allocations, and function to node allocations. Like OV-5, SV-4 may be hierarchical in nature and may have both a hierarchy or decomposition model and a system data flow model”. [DoDAF, v1.0, Vol. II]
The implementation of SV-4 is based on the same principles as OV-5.
As SV-4 should show hierarchies and flows of the System Functions, there is no single UML/SysML diagram that is able to do so. Therefore we suggest having two different products of the SV-4:
SV-4 diagram that is based on UML Class diagrams to define the hierarchy of System Functions.
SV-4 diagram that is based on UML Activity diagrams to define the flow of the System Functions.
User also may use:
Regular UML Class Diagram
Regular UML Activity Diagram
SysML Block Definition Diagram
SysML Activity Diagram
Any other MagicDraw diagram
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
System Function |
<<SystemFunction>> [Activity] |
|
System Data Flow |
<<SystemDataFlow>> |
N/A |
System Data Repository |
<<SystemDataRepository>> [DataStoreNode] |
|
System Function Action |
<<SystemFunctionAction>> [CallBehaviorAction] |
N/A |
Operational Activity |
See OV-5 data element definition |
|
System |
See SV-1 data element definition |
|
Systems Node |
See SV-1 data element definition |
|
System Data Exchange |
See SV-6 data element definition |
|
System Data Element |
See SV-6 data element definition |
A data transform that supports the automation of activities or information elements exchange. The system functions documented in SV-4 may be identified using the Service Component Reference Model (SRM), or some other system function taxonomy, and correlated to SV-1 and SV-2 systems.
Extends UML Activity.
implements: OperationalActivity [*] |
A set of Operational Activities that are implemented by System Function |
performedBy: System [*] |
Systems to which System Function is allocated |
allocatedAt: SystemsNode [*] |
Systems Nodes at which System Function is allocated |
produces: SystemDataExchange [*] |
System data produced by System Function |
consumes: SystemDataExchange [*] |
System data consumed by System Function |
subfunction: SystemFunction [*] |
Sub-functions into which the System Function is decomposed |
parent: SystemFunction [0..1] |
System Function that is decomposed |
performanceParameterSet: PerformanceParameterSet [*] |
Performance Parameter Set specified for System Function |
measurements: PerformanceMeasurementSet [*] |
A list of Performance Measured Sets with measured Performance Parameter Set values |
The SystemDataFlow of a system describes the data transferred between system Functions, external system data sources, or internal system data repositories.
Extends UML ControlFlow, UML ObjectFlow.
type: SystemDataElement [*] |
A list of System Data Elements that need to be exchanged |
System data store.
Extends UML DataStoreNode.
Call action that invokes System Function directly.
Extends UML CallBehaviorAction.
Figure 31 SV-4 profile diagram
Creation of SV-4 is very similar to OV-5.
We do recommend starting with the SV-4 System Function Hierarchy, because MagicDraw will be able to create SV-4 System Function Flow automatically from the data in the SV-4 flow definition.
SV-4 System Function Hierarchy
Use SV-4 specific toolbar to create hierarchies of the System Functions. Use Composition (Associaton) as main path between System Functions. As UML Activity is a UML Classifier, it can be used in the structure diagrams.
SV-4 System Function Flow
This is very similar to UML Activity diagram. Drawing System Functions will result in creation of Call Behavior Actions with System Function assigned as behavior.
Operational Activities from OV-5 are implemented by System Functions (property implements).
Systems from SV-1/SV-2 perform the System Functions (property performedBy).
Systems Nodes from SV-1/SV-2 group or host the System Functions (property allocatedAt).
System Functions produce and consume the System Data Exchange from SV-6 (properties produces and consumes).
System Data Flow has the System Data Element from SV-6 as type (property type).
Figure 32 SV-4 sample (hierarchy)
Figure 33 SV-4 sample (flow)
“Operational Activity to Systems Function Traceability Matrix is a specification of the relationships between the set of operational activities applicable to architecture and the set of system functions applicable to that architecture. The Framework uses the terms activity in the OVs and function in the SVs to refer to essentially the same kind of thing—both activities and functions are tasks that are performed, accept inputs, and develop outputs.” [DoDAF, v1.0, Vol. II]
SV-5 is a matrix based on dependency matrix in MagicDraw.
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
Operational Activity |
See OV-5 data element definition |
|
System Function |
See SV-4 data element definition |
Figure 34 SV-5 profile diagram
When user will create SV-5 matrix in the row scope he will be provided with a scope selection for the System Functions. In the column scope he will be provided with a scope selection for the Operational Activities. MagicDraw will find all System Functions and Operational Activities in the given scope and put them as column and row elements. The matrix cells will be filled according to relations between System Functions and Operational Activities (calculated from implementedBy property for Operational Activity and implements property for System Function).
Operational Activities from OV-5 are used in SV-5.
System Functions from SV-4 are used in SV-5.
Figure 35 SV-5 sample
“The Systems Data Exchange Matrix specifies the characteristics of the system data exchanged between systems. This product focuses on automated information exchanges (from OV-3) that are implemented in systems. Non-automated information exchanges, such as verbal orders, are captured in the OV products only. System data exchanges express the relationship across the three basic architecture data elements of an SV (systems, system functions, and system data flows) and focus on the specific aspects of the system data flow and the system data content.
The focus of SV-6 is on how the system data exchange is implemented, in system-specific details covering periodicity, timeliness, throughput, size, information assurance, and security characteristics of the exchange. In addition, the system data elements, their format and media type, accuracy, units of measurement, and system data standard are also described in the matrix.“ [DoDAF, v1.0, Vol. II]
SV-6 is a document, which is implemented as MagicDraw report, using model information mainly from SV-1.
Note. SV-6 is a product similar to OV-3. Therefore OV-3 implementation concepts will be reused.
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
System Data Exchange |
<<SystemDataExchange>> [InformationFlow] |
|
System Data Element |
<<SystemDataElement>> [Class] |
|
Information Exchange |
See OV-3 data element definition |
|
Information Element |
See OV-3 data element definitions |
|
Interface |
See SV-1 data element definition |
|
System Function |
See SV-4 data element definition |
|
Standard |
See TV-1 data element definition |
An act of exchanging system data between two distinct Systems and the characteristics of the act, including System Data Element that needs to be exchanged and the attributes associated with System Data Element (e.g., content) as well as attributes associated with System Data Exchange such as timeliness.
Extends UML Information Flow.
identifier: String |
Identifier of System Data Exchange – usually based on the relevant Needline, Interface, and Information Exchange |
consumedBy: SystemFunction [*] |
A list of System Functions that consume system data |
producedBy: SystemFunction [*] |
A list of System Functions that produce system data |
transactionType: String |
Type of exchange |
interoperabilityLevelAchievable: String |
Level of Information Systems Interoperability (LISI) achieved or achievable through the exchange |
criticality: String |
The criticality assessment of the information being exchanged in relationship to the mission being performed |
periodicity: String |
Frequency of System Data Exchange transmission – may be expressed in terms of worst case or average frequency |
timeliness: String |
Allowable time of delay this system data can tolerate and still be relevant to the receiving system |
throughput: String |
Bits or bytes per time period – may be expressed in terms of maximum or average throughput required |
size: String |
Size of system data |
IAAccessControl: String |
The class of mechanisms used to ensure only those authorized that can access a specific System Data Element |
IAAvailability: String |
The relative level of effort required to be expended to ensure that the system data can be accessed |
IAConfidentiality: String |
The kind of protection required for system data to prevent unintended disclosure |
IADisseminationControl: String |
The kind of restrictions on receivers of system data based on sensitivity of system data |
IAIntegrity: String |
The kind of requirements for checks that the content of the system data element has not been altered |
IANonRepudiationConsumer: String |
The requirements for unassailable knowledge that the system data sent was consumed by the intended recipient |
IANonRepudiationProducer: String |
The requirements for unassailable knowledge that the system data received was produced by the stated source |
protectionTypeName: String |
The name for the type of protection |
protectionDurationCode: String |
The code that represents how long the system data must be safeguarded |
protectionSuspenseCalendarDate: String |
The calendar date on which the designated level of safeguarding discontinues for a specific system data element |
classification: String |
Classification code for the System Data Element |
classificationCaveat: String |
A set of restrictions on system data of a specific classification. Supplements a security classification with system data on access, dissemination, and other types of restrictions |
releasability: String |
The code that represents the kind of controls required for further dissemination of system data |
securityStandard: Standard |
System Data Exchange security standard |
automates: InformationExchange [*] |
Information Exchanges automated by System Data Exchange |
dataElement: SystemDataElement [1] |
System Data Element that is exchanged via System Data Exchange |
performanceParameterSet: PerformanceParameterSet [*] |
Performance Parameter Set specified for System Data Exchange |
measurements: PerformanceMeasurementSet [*] |
A list of Performance Measured Sets with measured Performance Parameter Set values |
The architecture data element or type that stores data from the architecture domain (i.e., it has a value) that is produced or consumed by a System Function and that has System Data Exchange attributes.
Extends UML Class
identifier: String |
Identifier of System Data Element – based
on the relevant System Data Flow. System Data |
content: String |
The system data that is carried by the exchange |
formatType: String |
Application level format with parameters and options used, or other relevant protocol |
mediaType: String |
Type of media |
accuracy: String |
Description of the degree to which the system data conforms to actual fact as required by the System or System Function |
unitOfMeasurement: String |
Units used for system data |
systemDataStandard: Standard |
System Data Standard such as DoD XML Registry |
dataExchange: SystemDataExchange [*] |
A list of System Data Exchanges that exchange System Data Element |
implements: InformationElement [0..1] |
Information Element that is implemented by System Data Element |
performanceParameterSet: PerformanceParameterSet [*] |
Performance Parameter Set specified for System Data Element |
measurements: PerformanceMeasurementSet [*] |
A list of Performance Measured Sets with measured Performance Parameter Set values |
Figure 36 SV-6 profile diagram
OV-2 and SV-1 has to be created upfront in order to generate the SV-6.
If OV-2 and SV-1 are created according to MagicDraw’s suggested way – Information Exchanges, System Data Exchanges and System Data elements are fully described, there is nothing more to model in order to get the SV-6. Go to MagicDraw report engine and run the generation of the SV-6.
SV-1 has to be created upfront in order to generate the SV-6.
If SV-2 is created according to MagicDraw’s suggested way – Interfaces, System Data Exchanges and System Data Elements are fully described, there is nothing more to model in order to get the SV-6. SV-6 just gathers information about System Data Exchanges, System Data Elements and attributes of System Data Exchange and generates the document. Report may be generated for whole model or for selected scope.
In System Data Exchange Matrix report information about System Data Exchange attributes are grouped according to System Data Exchange attributes types:
System Data Exchange Associations section associates System Data Exchange with producing and consuming Systems and System Functions.
System Data Element Description section provides information about specific attributes of System Data Element: name, identifier, content, format type, media type, accuracy, unit of measurement, and data standard.
Nature of Transaction section includes the list of System Data Exchange attributes that specifies nature of transaction: transaction type, interoperability level achieved, and criticality.
Performance Attributes section defines System Data Exchange performance attributes: periodicity, timeliness, throughput, and size.
Information Assurance section lists System Data Exchange information assurance attributes: access control, availability, confidentiality, dissemination control, integrity, non-repudiation producer and non-repudiation consumer.
Security section presents System Data Exchange security attributes: protection (type name, duration, date), classification, classification caveat, releasibility, and security standard.
In each section items are sorted according to System Data Exchange identifier.
User can customize report by selecting System Data Exchange attributes sections that should be included to the report. Inside each section the list of System Data Exchange attributes can also be customized.
Information Exchanges from OV-2 are used in System Data Exchanges (property automates)
Interfaces from SV-1 are used in SV-6 (property interface).
System Data Elements from SV-11 are used in SV-6 (property DataElement)
System Data Exchanges are consumed or produced by System Function (properties consumedBy and producedBy)
System Data Exchange may use a Standard from TV (property securityStandard)
Figure 37 SV-6 sample
“The Systems Performance Parameters Matrix product specifies the quantitative characteristics of systems and system hardware/software items, their interfaces (system data carried by the interface as well as communications link details that implement the interface), and their functions. It specifies the current performance parameters of each system, interface, or system function, and the expected or required performance parameters at specified times in the future.
In more detail, SV-7 builds on SV-1, SV-2, SV-4, and SV-6 by specifying performance parameters for systems and system hardware/software items and their interfaces (defined in SV-1), communications details (defined in SV-2), their functions (defined in SV-4), and their system data exchanges (defined in SV-6).” [DoDAF, v1.0, Vol. II]
SV-7 in a table that is implemented as special GUI in MagicDraw. User will be provided a special table-like GUI for filling out the SV-7 data. As in MagicDraw everything is based on the underlying model, creating SV-7 will also create the UML model.
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
Performance Parameter Set |
<<PerformanceParameterSet>> [Class] |
|
Performance Parameter Type |
<<PerformanceParameterType>> [Property] |
|
Performance Measurement Set |
<<PerformanceMeasurementSet>> [InstanceSpecification] |
|
Performance Measurement |
<<PerformanceMeasurement>> [Slot] |
|
Time Period |
See the Time definitions |
The set of technical performance characteristics. Performance Parameter Set can be specified for System, Hardware or Software Item, System Function, Communications Link, Communications Systems, Communications Network, LAN, WAN, MAN, System Data Element and System Data Exchange.
Performance Parameter Set has Performance Parameter Types as child elements.
Extends UML Class.
measuredSystems: Standards/PerformanceSubject [*] |
Performance subjects for which Performance Parameter Set is specified. Performance Subjects are System, Hardware or Software Item, System Function, Communications Link, Communications Systems, Communications Network, LAN, WAN, MAN, System Data Element and System Data Exchange. |
Thi is the technical performance characteristic measured. Grouped by Performance Parameter Set.
Extends UML Property.
unitOfMeasure: String |
Unit of performance parameter measurement |
thresholdValue: String |
Value of Performance Parameter Type that is acceptable at the indicated time |
objectiveValue: String |
Desired operational goal, beyond which any gain in utility does not warrant additional expenditure |
This is an instance of Performance Parameter Set that contains actual measured values of Performance Parameter Set. Measured values are taken for specified Time Period. Performance Measurement elements are child elements of Performance Measurement Set. Holds references to the measured subject and time at which the measurement was performed.
Extends UML InstanceSpecification.
timePeriod: TimePeriod [1] |
Time Period when the measurements were/will be performed |
measuredSystem: Standards/Performance Subject [1] |
System view element (System, Hardware or Software Item, System Function, Communications System, Communications Link, Communications Network, LAN, WAN, MAN, System Data Element, System Data Exchange) for which performance parameters values are measured |
Actual measured value of Performance Parameter Type.
Extends UML Slot.
Figure 38 SV-7 profile diagram
Performance Parameter Sets can be accessed from DoDAF main menu. Straight from Performance Parameter Sets dialog user can create Performance Parameter Sets and assign them for Performance Subjects. Made changes will be automatically applied for Performance Subjects specifications.
Performance Parameters Types can be defined on Performance Parameter Set specification. It can be invoked straight from Performance Parameter Sets dialog.
For each Performance Parameter Type objective value, threshold value and unit of measure can be specified.
When user will create SV-7 in the row scope he will have to select Standards/Performance Subjects (System, Hardware or Software Item, System Function, Communications System, Communications Link, Communications Network, LAN, WAN, MAN, System Data Element, System Data Exchange) for which Performance Parameter Types values will be measured. In the column scope he will have to select Time Periods when the measurements will be performed. After that, user will be provided with a special GUI-based table, where rows will be Standards/Performance Subjects (Systems, System Functions, etc) and Performance Parameter Types. Columns will be collected from the selected Time Periods. User will fill in the cells, filling the measurement result for a Performance Measurement Type at a specific Time Period.
Despite this is a product that does not map to any diagram; DoDAF model will be also created in order to keep integrity with the rest of the model.
Systems from SV-1/SV-2 will be used in SV-7
Hardware or Software Items from SV-1/SV-2 will be used in SV-7
System Functions from SV-4 will be used in SV-7
Time Periods from Time Definitions will be used in SV-7
Figure 39 SV-7 sample
Figure 40 SV-7 sample model
“The Systems Evolution Description captures evolution plans that describe how the system, or the architecture in which the system is embedded, will evolve over a lengthy period of time. Generally, the timeline milestones are critical for a successful understanding of the evolution timeline.
SV-8, when linked together with other evolution products such as SV-9 and TV-2, provides a clear definition of how the architecture and its systems are expected to evolve over time. In this manner, the product can be used as an architecture evolution project plan or transition plan.” [DoDAF, v1.0, Vol. II]
SV-8 is a diagram that is based on a UML State Machine Diagram in MagicDraw. There is no standard way to do what, but we find semantic similarities between milestone and state – you can call a milestone a certain state of the subject system.
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
Milestone |
<<Milestone>> [State] |
|
System |
See SV-1 data element definition |
|
Time Period |
See the Time definitions |
A scheduling event that signifies the completion of a major deliverable or a set of related deliverables.
Extends UML State.
version: String |
Milestone version |
timePeriod: TimePeriod [1] |
Time period for milestone |
systemGroup: System [*] |
Systems required to complete a milestone |
Figure 41 SV-8 profile diagram
Creating is basically equal to creation of a regular UML statemachine diagram. Create a set of connected milestones. Then assign Time Periods and Systems required for each Milestone.
Systems from SV-1/SV-2 are used in Milestones.
Time Periods are used in Milestones.
Figure 42 SV-8 sample
“The Systems Technology Forecast defines the underlying current and expected supporting technologies. It is not expected to include predictions of technologies as with a crystal ball. Expected supporting technologies are those that can be reasonably forecast given the current state of technology and expected improvements. New technologies should be tied to specific time periods, which can correlate against the time periods used in SV-8 milestones.” [DoDAF, v1.0, Vol. II]
SV-9 in a table that is implemented as special GUI in MagicDraw. User will be provided a special table-like GUI for filling out the SV-9 data. As in MagicDraw everything is based on the underlying model, creating SV-9 will also create the UML model.
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
Technology |
<<Technology>> [Class] |
|
Technology Forecast Profile |
<<TechnologyForecastProfile>> [Package] |
|
Timed Technology Forecast |
<<TimedTechnologyForecast>> [Usage] |
N/A |
Time Period |
See the Time definitions |
|
Standard |
See TV-1 data element definition |
|
Standards Profile |
See TV-1 data element definition |
|
Reference Model |
See TV-1 data element definition |
|
Timed Standards Forecast |
See TV-2 data element definition |
Technology.
Extends UML Class
Describes a set of Technologies that can emerge in specific Time Period. The list of Technologies is coordinated with architecture transition plans. It will be a root package for adding the SV-9 data. As an example a system might be written initially in C++, then Java, and then an emerging language that is predicted to meet the needs of the architecture. The forecast used to show both the trusted and available technology for an architecture, while showing technologies in the future that can be applied for various reasons.
Extends UML Package.
timePeriod: TimePeriod [1] |
Time Period for which Technology Forecast Profile is made |
basedOn: ReferenceModel [*] |
Reference Models on which Technology Forecast Profile is based |
basedOn: StandardsProfile [*] |
Standards Profiles on which Technology Forecast Profile is based |
Relationship used to relate prediction about availability of emerging technology to System View element (System, Hardware or Software Item, System Function, Communications System, Communications Link, Communications Network, LAN, WAN, MAN, System Data Element, System Data Exchange) and Time Period for which forecast is made.
Basically it will be invisible to the user, as user will work with special UI, and the Timed Technology Forecast will be created in the underlying model.
Extends UML Usage.
discussion: String |
Textual notes regarding Technology status, likely commercial market acceptance, and risk assessment of adopting the technology forecast |
timePeriod: TimePeriod [1] |
Time Period for which technology forecast is made |
requiredBy: TimedStandardsForecast [*] |
A list of Timed Standards Forecasts that require Timed Technology Forecast |
retiredStandard: Standard [*] |
A list of current Standards that may be retired of phased out |
Figure 43 SV-9 profile diagram
When user will create SV-9 in the row scope he will have to select Services (or Systems) potentially impacted by technology forecast. In the column scope he will have to select Time Periods for which forecast will be made. After that, user will be provided with a special GUI-based table, where rows will be Services (or Systems). Columns will be collected from the selected Time Periods. User will fill in the cells, creating the Technology elements that are used at a specific Time Period.
Despite this is a product that does not map to any diagram; DoDAF model will be also created in order to keep integrity with the rest of the model.
Systems from SV-1/SV-2 may be used in SV-9 in order to show the applied technologies.
Figure 44 SV-9 sample
Figure 45 SV-9 sample model
“Systems rules are constraints on an architecture, on a system(s), or system hardware/software item(s), and/or on a system function(s). While other SV products (e.g., SV-1, SV-2, SV-4, SV-11) describe the static structure of the Systems View (i.e., what the systems can do), they do not describe, for the most part, what the systems must do, or what it cannot do.” [DoDAF, v1.0, Vol. II]
SV-10a is similar to OV-6a.
System Rule is implemented as UML Constraint in MagicDraw, so every DoDAF element in MagicDraw project can have an Operational Rule assigned.
SV-10a is a document, which is implemented as MagicDraw report, using model information mainly from OV products.
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
System Rule |
<<SystemRule>> [Constraint] |
|
Statement that defines or constrains some aspect of the mission, or the architecture. In contrast to Operational Rule, System Rule focuses on constraints imposed by some aspect of operational performance requirements that translate into system performance requirements. The rule is described in low detail and is primarily a human readable rule. The rule focuses on aspects of systems design and implementation.
Extends UML Constraint.
type: RuleType [1] = Structural Assertion |
System Rule type. Possible values are defined in the RuleType enumeration: Structural Assertion Action Assertion Derivation |
Figure 46 SV-10a profile diagram
In general SV-10a is just a collection of Operational Rules (UML constraints) from the model compiled in a document. User may generate report for whole project or for selected scope.
A System Rule can be applied to any element in the DoDAF model.
In Systems Rules Model report System Rules are grouped according to type:
Structural assertions are added to “Structural Assertions” section of the report.
Action assertions are added to “Action Assertions” section of the report.
Derivations are added to “Derivations” section of the report.
Inside each group System Rules are listed in numbered manner and sorted according to System Rule name. Below each System Rule name constraint specification and information about constrained elements is provided.
User can customize report by selecting the type of System Rules, for which report should be generated. The list of constrained elements may also be included optionally.
The SV-10a is a collection of System Rules from the rest of the model.
Figure 47 SV-10a sample
“The Systems State Transition Description is a graphical method of describing a system (or system function) response to various events by changing its state. The diagram basically represents the sets of events to which the systems in the architecture will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action. SV-10b can be used to describe the detailed sequencing of system functions described in SV-4.” [DoDAF, v1.0, Vol. II]
SV-10b is a diagram that is based on UML State Machine diagram.
No additional mapping to UML is needed for producing SV-10b.
This is implemented as a UML State Machine diagram.
Systems, Systems Nodes from SV-1 may have state machines as UML property Owned Behavior.
System Functions from SV-4 may have state machines as UML property Owned Behavior.
Figure 48 SV-10b sample
“The Systems Event-Trace Description provides a time-ordered examination of the system data elements exchanged between participating systems (external and internal), system functions, or human roles as a result of a particular scenario. Each event-trace diagram should have an accompanying description that defines the particular scenario or situation. SV-10c in the Systems View may reflect system-specific aspects or refinements of critical sequences of events described in the Operational View.” [DoDAF, v1.0, Vol. II]
SV-10c is a diagram that is based on UML Sequence Diagram.
No additional mapping to UML is needed for producing SV-10c.
This is a regular UML sequence diagram. You may drag in the objects from other DoDAF product from the data browser to this diagram in order to create lifelines.
SV elements may be used as types for the interaction attributes that will be set as represents property for the lifelines in SV-10c.
Figure 49 SV-10c sample
“The Physical Schema product is one of the architecture products closest to actual system design in the Framework. The product defines the structure of the various kinds of system data that are utilized by the systems in the architecture.
SV-11 is an implementation-oriented data model that is used in the Systems View to describe how the information requirements represented in Logical Data Model (OV-7) are actually implemented. Entities represent (a) system data flows in SV-4, (b) system data elements specified in SV-6, (c) triggering events in SV-10b, and/or (d) events in SV-10c.” [DoDAF, v1.0, Vol. II]
SV-11 is a diagram that is based UML Class Diagram.
User also may use:
Regular UML Class Diagram
SysML Block Definition Diagram
Any other MagicDraw diagram
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
Information Element |
See OV-3 data element definitions |
|
System Data Element |
See SV-6 data element definition |
Figure 50 SV-11 profile diagram
SV-11 is a regular class diagram with System Data Elements used instead of a UML Class.
It is likely that a lot of System Data Elements will be created to this point, so user can just drag those elements to the diagram from the browser tree.
System Data Elements defined in SV-6 are reused in SV-11.
System Data Element may implement Information Element from OV-6.
Figure 51 SV-11 sample