Systems View Products 

 SV-1. Systems Interface Description 

SV-1. Description

“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. Implementation in MagicDraw

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:

 

SV-1. UML Profile for DoDAF

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

System

Description

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. 

Attributes

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

 SystemsNode

Description

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. 

Attributes

implements: OperationalNode [*]

Operational Nodes housed by Systems Node

allocatedFunctions: SystemFunction [*]

System Functions allocated at Systems Node

Interface

Description

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)

Attributes

supportedNeedline: Needline [1]

Needline depicted by Interface

implementedBy: InterfaceImplementer [*]

A set of Communications Links and Communications Paths that implement Interface

SystemUsage

Description

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

 SystemsNodeUsage

Description

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.

 OrganizationalResourceUsage

Description

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.

 Hardware/SoftwareItem

Description

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. 

Attributes

vendors/source: String

Source of system Software or Hardware Item

SV-1. Profile diagram

Figure 23 SV-1 profile diagram 

SV-1. Creating the product

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.

SV-1.  Relationships to other products

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)

SV-1. Sample

Figure 24 SV-1 sample (Systems Nodes)

Figure 25 SV-1 sample (Systems)

Figure 26 SV-1 sample (Systems Node internal)

SV-2. Systems Communications Description 

SV-2. Description

“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. Implementation in MagicDraw

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:

 

SV-2. UML Profile for DoDAF

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

 InterfaceImplementer

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.

Attributes

Implements: Interface [0..1]

Interface implemented by Interface Implementer

 CommunicationsSystem

Description

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.

CommunicationsLink

Description

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

Attributes

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

 CommunicationsPath

Description

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. 

Attributes

communicationLinks: CommunicationsLink [1..*]

Communications Links contained by Communications Path

CommunicationsNetwork

Description

Communications Network is a set of Systems and Communications Links.

Derives from System. 

Attributes

securityClassification: String

Classification of System Data that Communications Network is allowed to carry

LAN

Description

A subtype of Communications Network defining local area network (LAN).

Derived from CommunicationsNetwork.

WAN

Description

A subtype of Communications Network defining wide area network (WAN).

Derived from CommunicationsNetwork.

 MAN

Description

A subtype of Communications Network defining metropolitan area network (MAN).

Derived from CommunicationsNetwork.

SV-2. Profile diagram

Figure 27 SV-2 profile diagram 

SV-2. Creating the product

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.

SV-2. Relationships to other products

Interfaces from SV-1 are implemented by Communication Links in SV-2 (property implements).

SV-2. Sample

Figure 28 SV-2 sample 

SV-3. Systems-Systems Matrix 

SV-3. Description

“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. Implementation in MagicDraw

SV-3 is a matrix based on dependency matrix in MagicDraw.

SV-3. UML Profile for DoDAF

DoDAF Element Type

UML Stereotype [metaclass]

Notation

System

See SV-1 data element definition

Interface

See SV-1 data element definition

SV-3. Profile Diagram

Figure 29 SV-3 profile diagram 

SV-3. Creating the product

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. Relationships to other products

SV-3 uses Systems and Interfaces from SV-1 and SV-2.

SV-3. Sample

Figure 30 SV-3 sample 

SV-4. Systems Functionality Description 

SV-4. Description

”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

SV-4. Implementation in MagicDraw

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:

User also may use:

 

SV-4. UML Profile for DoDAF

DoDAF Element Type

UML Stereotype [metaclass]

Notation

System Function

<<SystemFunction>> [Activity]

System Data Flow

<<SystemDataFlow>>
[ControlFlow, ObjectFlow]

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

SystemFunction

Description

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. 

Attributes

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

SystemDataFlow

Description

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. 

Attributes

type: SystemDataElement [*]

A list of System Data Elements that need to be exchanged

SystemDataRepository

Description

System data store.

Extends UML DataStoreNode.

SystemFunctionAction

Call action that invokes System Function directly.

Extends UML CallBehaviorAction.

SV-4. Profile diagram

Figure 31 SV-4 profile diagram 

SV-4. Creating the product

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.

SV-4. Relationship to other products

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).

SV-4. Sample

Figure 32 SV-4 sample (hierarchy)

Figure 33 SV-4 sample (flow)

SV-5. Operational Activity to Systems Functions Traceability Matrix 

SV-5. Description

“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. Implementation in MagicDraw

SV-5 is a matrix based on dependency matrix in MagicDraw.

SV-5. UML Profile for DoDAF

DoDAF Element Type

UML Stereotype [metaclass]

Notation

Operational Activity

See OV-5 data element definition

System Function

See SV-4 data element definition

SV-5.  Profile diagram

Figure 34 SV-5 profile diagram 

SV-5. Creating the product

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).

SV-5. Relationships to other products

Operational Activities from OV-5 are used in SV-5.

System Functions from SV-4 are used in SV-5.

SV-5. Sample

Figure 35 SV-5 sample 

SV-6. Systems Data Exchange Matrix 

SV-6. Description

“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. Implementation in MagicDraw

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. 

SV-6. UML Profile for DoDAF

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

SystemDataExchange

Description

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.

Attributes

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

SystemDataElement

Description

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

Attributes

identifier: String

Identifier of System Data Element – based on the relevant System Data Flow. System Data
Element identifier correlates with OV-3 Information Element

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

SV-6. Profile diagram

Figure 36 SV-6 profile diagram 

SV-6. Creating the Product

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-6. Creating the product

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. 

SV-6. Report template

In System Data Exchange Matrix report information about System Data Exchange attributes are grouped according to System Data Exchange attributes types:

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.

SV-6. Relationship to other products

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) 

SV-6. Sample

Figure 37 SV-6 sample 

 SV-7. Systems Performance Parameters Matrix 

SV-7. Description

“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. Implementation in MagicDraw

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.

SV-7. UML Profile for DoDAF

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

 PerformanceParameterSet

Description

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.

Attributes

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.

 PerformanceParameterType

Description

Thi is the technical performance characteristic measured. Grouped by Performance Parameter Set.

Extends UML Property.

Attributes

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

PerformanceMeasurementSet

Description

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.

Attributes

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

PerformanceMeasurement

Description

Actual measured value of Performance Parameter Type.

Extends UML Slot.

SV-7.  Profile Diagram

Figure 38 SV-7 profile diagram 

SV-7. Creating the Performance Parameter Sets

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.

SV-7. Creating the product

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.

SV-7. Relationships to other products

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

SV-7. Sample

Figure 39 SV-7 sample 

SV-7. Sample model

Figure 40 SV-7 sample model 

SV-8. Systems Evolution Description 

SV-8. Description

“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. Implementation in MagicDraw

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.

SV-8. UML Profile for DoDAF

DoDAF Element Type

UML Stereotype [metaclass]

Notation

Milestone

<<Milestone>> [State]

System

See SV-1 data element definition

Time Period

See the Time definitions

Milestone

Description

A scheduling event that signifies the completion of a major deliverable or a set of related deliverables.

Extends UML State.

Attributes

version: String

Milestone version

timePeriod: TimePeriod [1]

Time period for milestone

systemGroup: System [*]

Systems required to complete a milestone

SV-8. Profile diagram

Figure 41 SV-8 profile diagram 

SV-8. Creating the product

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.

SV-8. Relationship to other products

Systems from SV-1/SV-2 are used in Milestones.

Time Periods are used in Milestones.

SV-8. Sample

Figure 42 SV-8 sample 

SV-9. Systems Technology Forecast 

SV-9.  Description

“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. Implementation in MagicDraw

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.

SV-9. UML Profile for DoDAF

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

Description

Technology.

Extends UML Class

TechnologyForecastProfile

Description

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.

Attributes

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

TimedTechnologyForecast

Description

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. 

Attributes

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

SV-9. Profile Diagram

Figure 43 SV-9 profile diagram 

SV-9. Creating the product

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.

SV-9. Relationship to other products

Systems from SV-1/SV-2 may be used in SV-9 in order to show the applied technologies.

SV-9. Sample

Figure 44 SV-9 sample 

SV-9. Sample model

Figure 45 SV-9 sample model 

SV-10a. Systems Rules Model 

SV-10a. Description

“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. Implementation in MagicDraw

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.

 

SV-10a. UML Profile for DoDAF

DoDAF Element Type

UML Stereotype [metaclass]

Notation

System Rule

<<SystemRule>> [Constraint]

System Rule

Description

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. 

Attributes

type: RuleType [1] = Structural Assertion

System Rule type. Possible values are defined in the RuleType enumeration:

Structural Assertion

Action Assertion

Derivation

SV-10a. Profile Diagram

Figure 46 SV-10a profile diagram 

SV-10a. Creating the product

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.

SV-10a. Report Template

In Systems Rules Model report System Rules are grouped according to type:

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.

SV-10a. Relationship to other products

The SV-10a is a collection of System Rules from the rest of the model.

SV-10a. Sample

Figure 47 SV-10a sample

SV-10b. Systems State Transition Description 

SV-10b. Description

“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. Implementation in MagicDraw

SV-10b is a diagram that is based on UML State Machine diagram.

SV-10b. UML Profile for DoDAF

No additional mapping to UML is needed for producing SV-10b.

SV-10b. Creating the product

This is implemented as a UML State Machine diagram. 

SV-10b. Relationship to other products

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.

SV-10b. Sample

Figure 48 SV-10b sample 

SV-10c. Systems Event-Trace Description 

SV-10c. Description

“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. Implementation in MagicDraw

SV-10c is a diagram that is based on UML Sequence Diagram.

SV-10c. UML Profile for DoDAF

No additional mapping to UML is needed for producing SV-10c.

SV-10c. Creating the product

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-10c. Relationship with other products

SV elements may be used as types for the interaction attributes that will be set as represents property for the lifelines in SV-10c.

SV-10c. Sample

Figure 49 SV-10c sample 

 SV-11. Physical Schema

SV-11. Description

“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. Implementation in MagicDraw

SV-11 is a diagram that is based UML Class Diagram.

User also may use:

 

SV-11. UML Profile for DoDAF

DoDAF Element Type

UML Stereotype [metaclass]

Notation

Information Element

See OV-3 data element definitions

System Data Element

See SV-6 data element definition

SV-11.  Profile Diagram

Figure 50 SV-11 profile diagram 

SV-11. Creating the product

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.

SV-11. Relationship with other products

System Data Elements defined in SV-6 are reused in SV-11.

System Data Element may implement Information Element from OV-6.

SV-11. Sample

Figure 51 SV-11 sample