View MODAF:SV-1 Resource Interaction Specification View
Overview
The SV-1 System Resource Interface Specification is part of the MODAF System Viewpoint and one of the 47 MODAF views*.
Version & Date
Version 1.2.004.
+ = new at 1.2.004
The change history is derived from the definition of each MODAF view within the The MODAF System Viewpoint
viewpoint defining document from www.mod.uk/modaf.
Purpose
From The MODAF System Viewpoint (SV)
p4:
An SV-1 specifies the composition and interaction of resources.
Subject to Crown Copyright
Background*
From The MODAF System Viewpoint (SV)
p4:
The SV-1 links together the operational and systems architecture views by depicting how resources are structured and how they interact in order to realise the logical architecture specified in an OV-2, Operational Node Relationship Description. An SV-1 may represent the realisation of a requirement specified in an OV-2 (i.e. in a to-be architecture) and, consequently, there may be many alternative SV suites that provide candidate solutions that realise the operational requirement.
The SV-1 depicts interactions between resources. A resource interaction is a simplified representation of a pathway or network, usually depicted graphically as a connector (i.e. a line that can be labelled with supporting information). Note that interactions between systems (Artefacts used as systems) may be further specified in detail in the SV-2, Systems Communications Description series, and SV-6, Systems Data Exchange Matrix.
Resources may be decomposed in SV-1 to any level (i.e. depth) that the architect sees fit. When one resource is part of another, the architect must specify the context in which the part is used.
Subject to Crown Copyright
Description*
From The MODAF System Viewpoint (SV)
p5:
The primary purpose of an SV-1 is to show resource structure; i.e. to identify the primary sub- systems, posts and roles and their interactions. SV-1 contributes to user understanding of the structural characteristics of the capability. Resource structures may be identified in SV-1 to any level (i.e. depth) of decomposition the architect sees fit. An SV-1 may be adorned with nodes originally specified in OV-2. In this way, traceability can be established from the logical OV structure to the physical SV structure.
In its simplest form, an SV-1 can be used to depict systems and sub-systems, and identify the interfaces between them; however, this rarely adds more to that which can be shown in an SV-2, product. The real benefit of an SV-1 is its ability to show the human aspects of an individual architecture, and how these interact with systems. In addition, MODAF has the concept of a
capability configuration</q> which is used to gather together systems, assets and people into a configuration which can meet a specific capability.
From The MODAF System Viewpoint (SV)
p7:
Functions
MODAF adopts a simplified model where any resource may perform functions. SV-1 and SV-4, Functionality Description, provide complementary representations (structure and function). The functions from an SV-4 can optionally be overlaid on an SV-1.
Interactions in SV-1
In addition to depicting resources and their structure, SV-1 addresses interaction relationships between resources. An interaction, as depicted in SV-1, is an indicator that data passes between one resource and another. In the case of systems, this can be described in further detail in an SV- 2b, System to System Port Connectivity Description. Interactions provide a specification for how the exchanges specified in OV-2 needlines are realised. A single needline shown in the OV-2 may translate into multiple interactions.
The actual implementation of an interaction may take more than one form (e.g. multiple physical links). Details of the physical links and communications networks that implement the interfaces are documented in SV-2. Resource Interactions are summarised in an SV-3, Resource Interaction Matrix. If SV-1 is developed as a composite structure model (e.g. in SysML, UML), Resource Ports may be used to convey how interactions are dealt with internal to the resource when the resource has parts. Resource Ports may also specify the interfaces they require or provide. Note that when connecting resources via interfaces and ports, the architecture is tight-coupled. For loose-coupled architectures, a service-oriented approach should be taken (see Service Oriented Views and SV- 12, Service Provision and Service Composition).
Interactions between resources need not be restricted to communication of data. An SV-1 may also show interactions where materiel, human resources or energy flow from one resource to another.
Data Objects
From The MODAF System Viewpoint (SV)
p5:
The data in an SV-1 can include:
- Artefact
- Organisational Resource (Organisation Type, Post Type, Role Type)
- Software
- Physical Architecture (Capability Configuration, System Implementation)
- Resource Composition
- Resource Interaction (flows of data, materiel, human resources or energy)
- Traceability to Nodes (OV-2) and Capabilities (StV-2)
Full size:File:MODAF SV-1 mm dataObjects.gif
Subject to Crown Copyright
Note that this diagram shows that the following can be included:
Note that the descriptive text shows that the following can also be included:
- Node
- Function
- Resource Port - composite structure diagram form
- Resource Port Connector - composite structure diagram form
Presentation
From The MODAF System Viewpoint (SV)
p5:
- Topological (connected shapes)
- UML composite structure diagram
- SysML blocks diagram
Configuration History
- 1.2.004 adds Resource Port and Resource Port Connector - see composite structure presentation and Resource Interface
Comments
Although the description states that the SV-1 is primarily a structural view (although it is titled SV-1 Resource Interaction Specification View
) there is little difference between it and a SV-2 as a result of the way it is specified - in terms of identifying interfaces/interactions it is perfectly legal to use a SV-1. You only need a SV-2 if you need to characterise the interaction in terms of protocol. At 1.2.004 there is even less distinction since with the composite structure form the SV-1 can show ports and port connections. As a result structure and interactions can appear in either or both a SV-1 and SV-2.
As resource interactions can be shown for human resources in both the SV-1 and SV-2 it makes no sense to say real benefit of an SV-1 is its ability to show the human aspects of an individual architecture, and how these interact with systems
, particularly if the primary purpose of an SV-1 is to show resource structure
. Mixed messages.
As a result there is no clear separation of purpose or concerns addressed between the SV-1 and SV-2.
The data objects list is incomplete since Nodes, Functions, Ports and Port Connections may be overlaid on the SV-1.
Note that the MODAF::OV-4 Organisational Relationships Chart View also could be a SV-1 since it uses a subset of those metamodel elements (Organisational Resource) defined for the SV-1.
References
- The MODAF System Viewpoint (OV). 26th April 2010. https://www.mod.uk/DefenceInternet/AboutDefence/CorporatePublications/InformationManagement/MODAF/TheSystemViewpointsv.htm
Other Frameworks
See also:
- DNDAF::SV-1 Systems Interface Description Subview
- DODAF::SV-1 Systems Interface Description Model
- NAF::NSV-1 System Interface Description Subview
- TRAK::SV-01 Solution Structure View for the structure and TRAK::SV-02 Solution Resource Interaction View for the interfaces/exchanges
Category:Framework -> View
Category:MODAF -> View
Category:Solution