SVp-01:Solution Structure Viewpoint

Version

13

Date

5th February 2013

Overview

The SVp-01 - Solution Structure Viewpoint is part of the TRAK Solution Perspective and one of the 21 TRAK Architecture Viewpoints.

The SVp-01 provides the means to describe solution structure in terms of parts, governance, membership, physical dependency, hosting of software and extent. ‘extent’ refers to the extent of a Role which can be used to indicate governance or jurisdiction scope over parts of the solution.

The SVp-01 viewpoint is the specification for the SV-01 Solution Structure View.

Stakeholders Addressed

• Owner of Solution
• Acquirer of Solution
• Developer of Solution
• Operator of Solution
• User of Solution
• Trainer of Solution
• Maintainer of Solution
• Disposer of Solution

Concerns Addressed

Full size:File:SVp 01 stakeholderConcerns.pdf

What does the solution consist of? Is it structured sensibly? What is the organisation structure / membership? How does responsibility (scope/jurisdiction) apply to the solution components?

Covered by TRAK IPR and licenses

Description

Describes solution structure in terms of parts, governance, membership, dependency and extent.

Covered by TRAK IPR and licenses

Mandatory Metamodel Tuples

Full size:File:SVp 01 fragment mandatoryTuples.jpg

Configuration

• Resource has part Resource (System, Physical, Software, Organisation, Job or Role)
• Physical physically depends on Physical
• Software hosted on Physical
• Physical contains System
• Physical contains Physical
• System is configured with Resource

Governance

• Job governs Job
• Organisation is member of Organisation
• Organisation governs Organisation

Role Extent

• Organisation plays Role
• Job plays Role
• Role extends to Resource (System, Physical, Software, Organisation, Job or Role)

Solution Realises ...

• Resource realises Node

where Resource = System, Physical, Software, Organisation, Job or Role

Organisation realises Enterprise

System realises Capability

Covered by TRAK IPR and licenses

Note: physically depends on has an attribute:

dependency type = ‘Unknown’, ‘Proximity’ or ‘Alignment’

which can be used to describe whether 2 things depend on each other in terms of location or, more specifically, an alignment.

Optional Metamodel Tuples

• Concern about Resource (System, Physical, Software, Organisation, Job or Role)
• Resource traces to Document
• Resource traces to Requirement
• Standard governs Resource

Covered by TRAK IPR and licenses

If any of these optional metamodel elements are added then the appropriate TRAK Master Architecture View must be provided.

Well-Formedness

A SV-01 view shall contain:

EITHER [configuration]

• at least the Resource (the subject of the view) connected to another Resource using is configured with or has part or hosted on or physically depends on or contains (as permitted by the metamodel)

OR [governance]

• at least an Organisation or a Job (the subject of the view)
• that Organisation or Job connected to another Organisation or Job using governs/is member of or governs respectively

OR [role extent]

• at least 1 Organisation or Job (the subject of the view)
• the subject Organisation or Job connected to at least 1 Role (the subject role)
• the subject role connected to at least 1 System

Covered by TRAK IPR and licenses

Presentation

• block diagram (Resource = block, TRAK metamodel relationship = line with text label and direction indicator)

[configuration]

[governance]:

[role extent]:

Covered by TRAK IPR and licenses

Examples

See SV-01

Views Needed to Construct

• CV-01 specified by CVp-01  (if ‘... realises Node’ shown) - master architecture view for Node

See Minimum Allowed View Sets

Covered by TRAK IPR and licenses

Consistency Rules

• If the SV-01 is used to define the extents of system authority, manufacturer, design authority or independent safety authority using Resource plays Role extends to (different) Resource these must be consistent with the values of role-based attributes for System (system authority,  design authority, manufacturer, independent safety authority) or Resource (design authority, manufacturer, independent safety authority).
• Functional Realisation of Node.: IF {Node conducts Concept Activity (CV-05)} AND {Resource performs Function realises (same) Operational Activity (SV-04 + SV-05) } THEN {Resource realises Node} must be made on the SV-01.
• Topological Realisation of Node : IF {Node has Need (CV-01) } AND {Resource Interaction realises (same) Need } THEN {Resource realises Node} must be made on the SV-01

If System is configured with Organisation is made in the SV-01:The Organisation that governs the Project cannot itself be part of the Solution since the former is part of the model of the business and the latter will be part of the model of the thing delivered or developed. The governing organisation might well provide the resource to deliver the project but it is a different organisation to that in the solution - it is important to keep these 2 models distinct.

• { organisation in Organisation governs Project}

NOT EQUAL

• { organisation IN

{

• (same) Project undertakes Project Activity delivers / removes (System is configured with Organisation)

OR

• (System is configured with Organisation) is necessary for Project Activity AND (same) Project undertakes Project Activity

OR

• (same) Project owns Milestone marks introduction of /marks removal of (System is configured with Organisation)

}

This also comes into play if Organisation owns Project is made in the PrV-01

Covered by TRAK IPR and licenses

Further rules are applied through the TRAK Bye Laws

Configuration History

The TRAK Viewpoints project on Sourceforge (trakviewpoints.sourceforge.net) maintains a version-controlled repository. The change record is at /trakviewpoints.svn.sourceforge.net/viewvc/trakviewpoints/trunk/?view=log

Comments

The SV-01 is the master architecture view for Resource (Job, Organisation, Physical, Role, Software, System)

The SV-01 provides 3 areas of coverage:

1. Describing organisational structure - governance, membership and roles as well as organisational breakdown.
2. Describing the extent or jurisdiction of roles
3. Describing classic system or product breakdown structure.

If you need to show the effect of time on responsibility extent use the PrV-03 Procurement Responsibility View.

Covered by TRAK IPR and licenses

References

• TRAK Enterprise Architecture Framework Viewpoints. trakviewpoints.sourceforge.net

Other Frameworks

There is no direct mapping onto DNDAF,DODAF, MODAF or NAF as the structural aspects of the solution are presented in their SV-1/SV-2/NOV-1/NOV-2 views together with exchanges at varying levels - there is no dedicated structural view of the solution.

The nearest equivalents are:

• Structural aspects of DNDAF::SV-1 Systems Interface Description Subview
• Structural aspects of DODAF::SV-1 Systems Interface Description Model (deprecated in favour of DODAF::SvcV-1 Services Context Description Model)
• Structural aspects of MODAF::SV-1 Resource Interaction Specification View and the MODAF::SV-2c System Connectivity Clusters View which shows how resources are organised (and covers exchanges)
• Structural aspects of NAF::NSV-1 System Interface Description Subview

Whilst in TRAK the organisational structure and communication between Roles and Jobs is covered using the SVp-01, other frameworks have dedicated architecture views:

• Organisation - Organisation structure is addressed by the DNDAF::OV-4a Organizational Relationships Chart Subview whereas Role - Organisation mapping and competence is addressed by the DNDAF::OV-4b Organization to Role/Skill Matrix Subview
• DODAF::OV-4 Organizational Relationships Chart Model
• MODAF::OV-4 - Organisational Relationships Chart View
• NAF::NOV-4 Organisational Relationship Chart Subview

Category:Framework -> Viewpoint
Category:Framework -> Specification
Category:Solution

Version & Date

30th September 2011

Configuration History

See change record for the TRAK metamodel at http://trakmetamodel.svn.sourceforge.net/viewvc/trakmetamodel/trunk/?view=log

Definition

One of the TRAK stereotypes within the the TRAK metamodel and part of the Solution Perspective.

From the TRAK metamodel:

A System is something that has complex and emergent behaviour or properties. It is also therefore classically more than the sum of its parts. It may be a soft system (touchy-feely people for example - something you can’t touch) or it may be a classic hard system expressed as hardware.

A composite structure representing the physical, software and human resources (and their interactions) in an enterprise.

Covered by TRAK IPR and licenses

Tests For

Tests Against

Not a System if any of the following apply

• the function(s) of the System can be purely described by the sum of the functions of the Resource with which the System is configured with i.e. no emergent behaviour
• configured with purely Physical - not 100% but you would normally only expect behaviour from a combination of Physical and either Software or Human Resource i.e. not a pile of bricks or inanimate structure

Attributes

Inherited Attributes:

• + from Resource

Covered by TRAK IPR and licenses

Implementation of TRAK Attribute Names and Values

The implementation of TRAK attributes in a tool is controlled by ‘TRAK. Implementation. Architecture Description Elements’ with respect to the case, spelling of attributes and format of values. See References section below.

Relationships

TRAK::System has the following relationships with other TRAK metamodel elements:

• Physical contains  TRAK::System
• TRAK::System realises  Capability
• TRAK::System is configured with  Physical
• TRAK::System is configured with  Software
• TRAK::System is configured with  Human Resource ( Organisation ,  Role,  Job)
• System is configured with TRAK::System
• Project Activity delivers TRAK::System
• Project Activity removes TRAK::System
• TRAK::System necessary for Project Activity
• Milestone marks introduction of TRAK::System
• Milestone marks removal of TRAK::System

Inherited relationships:

• + from Resource

Covered by TRAK IPR and licenses

Note: Roles such as System Authority, Design Authority, Manufacturer are defined using the SV-01 Solution Structure View  and the scope is defined using the extends to relationship between Resource and Role.

Configuration History

See change record for the TRAK metamodel at http://trakmetamodel.svn.sourceforge.net/viewvc/trakmetamodel/trunk/?view=log

Master Architecture View

Any System used within an architecture description of the system-of-interest must appear on a SV-01 Solution Structure View for the architecture description.

The SV-01 is the Master Architecture View for System.

Covered by TRAK IPR and licenses

Comments

Part of the Solution Perspective.

The current INCOSE Systems Engineering Handbook defines a system as:

an integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements.

This is why TRAK::System is defined as it is and why MODAF::System cannot be used in this sense.

A System need not be configured with anything - initially you might not have information to be able to describe the components. In this case it is a high level outline description and the components of the system can be defined later on.

A System could consist of purely Human Resource with no Physical or Software. In this case it would be a soft system.

Note: TRAK::System is quite different in definition from MODAF::System. This is why the TRAK and MODAF namespace prefixes (TRAK:: and MODAF::) are used here.

Other Frameworks

• DODAF::System
• MODAF::System
• NAF::System

References

• TRAK. Implementation. Architecture Description Elements http://sf.net/projects/trak/files/Implement TRAK/
• INCOSE?TP?2003?002?03.2. INCOSE Systems Engineering Handbook v. 3.2. January 2010 http://www.incose.org/ProductsPubs/products/sehandbook.aspx
• TRAK Enterprise Architecture Framework Metamodel. trakmetamodel.sourceforge.net

Category:Metamodel -> Stereotype
Category:Solution

Version & Date

6th December 2012

Configuration History

See change record for the TRAK metamodel at http://trakmetamodel.svn.sourceforge.net/viewvc/trakmetamodel/trunk/?view=log

Definition

Part of the Solution Perspective.

Part of the solution - a generic thing that refers to human-related and machine-related entities.

Covered by TRAK IPR and licenses

Tests For

Not applicable - not used in any TRAK architecture views.

Tests Against

Not applicable - not used in any TRAK architecture views.

Comments

• abstract
• parent class of System, Physical, Software, Human Resource
• not used in any TRAK view

Covered by TRAK IPR and licenses

At this abstract level there is no differentiation between man and machine.

Attributes

• id
• Location label
• Location code
• location (latitude, longitude, altitude)

Inherited attributes:

• + from Architecture Description Element
• + from Safety Monitored Element

Covered by TRAK IPR and licenses

Implementation of TRAK Attribute Names and Values

The implementation of TRAK attributes in a tool is controlled by ‘TRAK. Implementation. Architecture Description Elements’ with respect to the case, spelling of attributes and format of values. See References section below.

Relationships

Resource participates in the following relationships:

• Human Resource is a Resource
• System is a Resource
• Physical is a Resource
• Software is a Resource
• Resource exposes Port
• Resource performs Function
• Role extends to Resource

Covered by TRAK IPR and licenses

Configuration History

See change record for the TRAK metamodel at http://trakmetamodel.svn.sourceforge.net/viewvc/trakmetamodel/trunk/?view=log

Comments

Location conforms to RFC 5870.

Other Frameworks

• MODAF::Resource
• NAF::Resource

References

• TRAK Enterprise Architecture Framework Metamodel. http://trakmetamodel.sourceforge.net
• TRAK. Implementation. Architecture Description Elements http://sf.net/projects/trak/files/Implement TRAK/
• RFC 5870. A Uniform Resource Identifier for Geographic Locations. June 2010. http://tools.ietf.org/html/rfc5870

Category:Metamodel -> Stereotype
Category:Solution
Category:Architecture Perspective -> Solution

Version & Date

6th December 2012

Configuration History

See change record for the TRAK metamodel at http://trakmetamodel.svn.sourceforge.net/viewvc/trakmetamodel/trunk/?view=log

Definition

One of the TRAK stereotypes within the the TRAK metamodel and part of the Solution Perspective.

From the TRAK metamodel:

A physical thing. Can represent an equipment (which can host Software), a building or civil item, train etc.

Covered by TRAK IPR and licenses

Tests For

• bricks & mortar

Covered by TRAK IPR and licenses

Tests Against

• a System - systems are almost always not purely physical. They may have an essential part that is the Physical container but the system itself is formed from the collection and behavioural interaction of its essential parts
• the collection of people/resource (Organisation) that sits within the Physical (building) - often we give the same name to a headquarters building and to the organisation that is based within it.

Attributes

Inherited from:

• + from Resource

Covered by TRAK IPR and licenses

Implementation of TRAK Attribute Names and Values

The implementation of TRAK attributes in a tool is controlled by ‘TRAK. Implementation. Architecture Description Elements’ with respect to the case, spelling of attributes and format of values. See References section below.

Relationships

Physical participates in:

• Physical is a Resource
• Software is hosted on Physical
• System is configured with Physical
• Physical has part Physical
• Physical physically depends on Physical
• Physical contains Physical
• Physical contains System

Inherited relationships:

• + from Resource

Covered by TRAK IPR and licenses

Note: Roles such as Design Authority, Manufacturer are defined using the SV-01 Solution Structure View  and the scope is defined using the extends to relationship between Resource and Role.

Configuration History

See change record for the TRAK metamodel at http://trakmetamodel.svn.sourceforge.net/viewvc/trakmetamodel/trunk/?view=log

Master Architecture View

Any Physical used within an architecture description of the system-of-interest must appear on a SV-01 Solution Structure View for the architecture description.

The SV-01 is the Master Architecture View for Physical.

Covered by TRAK IPR and licenses

Comments

Can represent an equipment (which can host Software), a building or civil item, train etc.

Care is needed to distinguish when loose language is used between, for example, a HQ or Station as a building (=Physical) and the Organisation that might have the same name.

Other Frameworks

• MODAF::Physical Asset
• NAF::Physical Asset

References

• TRAK. Implementation. Architecture Description Elements http://sf.net/projects/trak/files/Implement TRAK/
• TRAK Enterprise Architecture Framework Metamodel. trakmetamodel.sourceforge.net

Category:Metamodel -> Stereotype
Category:Solution
Category:Architecture Perspective -> Solution

Title

SVp-07 Solution Sequence Viewpoint

Version

9

Date

13th April 2012

Overview

The SVp-07 Solution Sequence viewpoint is part of the TRAK Solution Perspective and one of the 21 TRAK Architecture Viewpoints.

The SVp-07 Solution Sequence Viewpoint provides the means to describe the order or sequence in which things happen within the solution. It elaborates the behaviour described by the SVp-04 Solution Function Viewpoint where functions are defined and allocated to parts of the solution and the exchanges described in the SVp-02 Solution Resource Interaction Viewpoint.

The SVp-07 architecture viewpoint is the specification for the TRAK::SV-07 Solution Sequence architecture view.

Stakeholders Addressed

• Owner of Solution
• Developer of Solution
• Acquirer of Solution
• Operator of Solution
• User of Solution
• Trainer of Solution
• Maintainer of Solution

Covered by TRAK IPR and licenses

Concerns Addressed

In what order do things need to happen?

Covered by TRAK IPR and licenses

Description

Describes the order in which functions or events occur.

Covered by TRAK IPR and licenses

Mandatory Metamodel Tuples

Functional Sequence

• Resource performs Function
• Function precedes Function
• Function triggers Interaction Element
• Interaction Element triggers Function

Interaction Sequence

• Resource Interaction from/to Resource
• Resource Interaction carries Interaction Element

where Resource = System, Physical, Software,  Organisation, Job or Role

Full size:File:SVp-07 mandatoryTuples.gif

Covered by TRAK IPR and licenses

Consistency rules apply where any exchange between Resources or functionality shown wrt Function.

Optional Metamodel Tuples

Context:

To establish what ‘thing’ is performing functional or interaction sequence and where it sits in the bigger picture:

• System is configured with Resource
• Organisation has part Job
• Organisation is member of Organisation
• Job plays Role

where Resource = System, Physical, Software, Organisation, Job or Role

• Function has part Function
• Interaction Element has part Interaction Element

Universal:

• Concern about Architecture Description Element
• Document traces to Architecture Description Element
• Requirement traces to Architecture Description Element
• Standard governs Architecture Description Element

If any of these optional metamodel elements are added then the appropriate TRAK Master Architecture View must be provided.

Covered by TRAK IPR and licenses

Well-Formedness

A SV-07 view shall contain:

Function Sequence

• at least one Resource (the subject of the view)
• the subject Resource must have at least 2 Functions
• every Function must be connected to another Function by EITHER (Function triggers Item triggers Function) OR (Function precedes Function)

Interaction Sequence

• at least 2 Resources (the subject of the view)
• each Resource pair is connected by a Resource Interaction

General

• a means of identifying the order in which all Functions/Resource Interactions occur e.g. by numbering or explicit layout on a time line

Covered by TRAK IPR and licenses

Presentation

Any diagram capable of showing order/sequence of events, state transitions etc.

• sequence diagram
• communication diagram

Interaction Sequence

Note: labelling shown is of the form: sequence identifier:Resource Interaction Identifier.

Function Sequence

showing the Function precedes Function tuple:

Covered by TRAK IPR and licenses

Examples

Views Needed to Construct

• SV-01 Solution Structure View (specified by viewpoint SVp-01)  - master architecture view for Resource (Job, Organisation, Role)
• SV-04 (specified by the SVp-04 Solution Function Viewpoint) - master architecture view for Function.

See Minimum Allowed View Sets

Covered by TRAK IPR and licenses

Consistency Rules

• any Interaction Elements and Resource Interactions needed to trigger Functions must be consistent with those defined on the SV-02:
  • IF (Resource performs Function triggers Interaction Element on SV-07) THEN ( Resource Interaction from (same) Resource carries (same) Interaction Element on SV-02)
  • IF (Interaction Element triggers Function performed by Resource SV-07) THEN ( Resource Interaction to (same) Resource carries (same) Interaction Element on SV-02)

• any Functions shown must be consistent with those defined on the SV-04:

  • IF Resource performs Function on SV-07 THEN ((same) Resource performs (same) Function on SV-04)

• any interchange between resources must be consistent with those via
  Resource-Resource Interaction-Resource shown in SV-02

• any linking of Resources using a Function and an Interaction Element to establish a sequence causes a SV-02 and SV-03 to be created if not already present :

  • Functional justification of resource interaction.: IF {Resource performs Function triggers Interaction Element (SV-07)} AND {(second) Resource performs (second) Function triggers (same) Interaction Element (SV-07) } THEN {{Resource Interaction from Resource to (second) Resource must be made in SV-02 AND (same) Resource Interaction supports Function and (same) Resource Interaction supports (second) Function must be made in SV-03}}.

Full size:File:SV 07 SV-02 SV-03 consistency.gif

Linking of 2 Resources’  Functions via Interaction Elements causes a SV-02 (asserting that a resource interaction between the 2 resources exists) and a SV-03 (mapping the resource interaction to the 2 functions involved in the sequence) to be created.

Covered by TRAK IPR and licenses

Configuration History

The TRAK Viewpoints project on Sourceforge (trakviewpoints.sourceforge.net) maintains a version-controlled repository. The change record is at trakviewpoints.svn.sourceforge.net/viewvc/trakviewpoints/trunk/?view=log

Comments

References

• TRAK Enterprise Architecture Framework Viewpoints. trakviewpoints.sourceforge.net

Other Frameworks

See also:

• DNDAF::SV-10b Systems State Transition Description Subview and DNDAF::SV-10c Systems Event-Trace Description Subview
• DODAF::SV-10b Systems State Transition Description Model and DODAF::SV-10c Systems Event-Trace Description Model (deprecated in favour of DODAF::SvcV-10b Services State Transition Description Model and DODAF::SvcV-10c Services Event-Trace Description Model)
• MODAF::SV-10b Resource State Transition Description View and MODAF::SV-10c Resource Event-Trace Description View
• NAF::NSV-10b Systems State Transition Description Subview and NAF::NSV-10c Systems Event-Trace Description Subview

Category:Framework -> Viewpoint
Category:Framework -> Specification
Category:Solution

Name

Architecture Description Dictionary View

Description

Part of the TRAK Management Perspective and one of the 21 TRAK architecture view types.

Defines each element used in the architecture description. This is used to explain to others what each element is intended to represent and is necessary in preserving the meaning. It is also necessary if an element is to be reused correctly and consistently.

Covered by TRAK IPR and licenses

Specification

Conforms to the MVp-01 Architecture Dictionary Viewpoint

Tool Support

•

Sparx Enterprise Architect

Applications or Uses

• dictionary / definition for each architecture description element described
• common / shared understanding with others e.g. other organisations
• common “pick list” for architecture description elements
• preserves knowledge / makes it easier to understand later on

Comments

Category:View
Category:Management

Name

Requirements & Standards View

Description

Part of the TRAK Management Perspective and one of the 21 TRAK architecture view types.

.

Describes the constraints that apply to an architecture element through requirements and standards or how standards depend on one another.

Covered by TRAK IPR and licenses

Specification

Conforms to the MVp-03 Requirements & Standards Viewpoint

Applications or Uses

• contracts standards assessment - normative documents applied through contract
  • identifying potential compliance problems
  • support contract negotiation

• requirements

  • requirement document structure
  • linking to requirement management tool
• standards hierarchy / dependence / precedence

Examples

Tool Support

• Sparx Enterprise Architect

Comments

Category:View
Category:Management

Solution Function View

Description

Part of the TRAK Solution Perspective and one of the 21 TRAK views.

Describes the function or behaviour of the solution or part of the solution.

Specification

Conforms to the SVp-04 Solution Function Viewpoint

Tool Support

• Sparx Enterprise Architect

Applications or Uses

Describing:

• process or activity
• functional hierarchy

Comments

Category:View
Category:Solution

Name

Solution Structure View

Description

Part of the TRAK Solution Perspective and one of the 21 TRAK architecture view types.

Describes solution structure in terms of parts, governance, membership, dependency and responsibility extent.

Covered by TRAK IPR and licenses

Specification

Conforms to the SVp-01 Solution Structure Viewpoint

Applications or Uses

Use to describe:

• configuration
• hosting of software
• physical dependency between 2 physical things
• membership of an organisation
• reporting/control in an organisation
• individual or organisational roles applying to a solution e.g. System Design Authority, Integration Authority, Control Authority, Supplier

Typical forms:

• system/product breakdown structure (SBS)/(PBS)
• organisation chart

See:

• Critical Design Review
• Representing Responsibility Extent and Roles
• Organisation Chart

Examples

Describing Organisation Structure

Passenger Focus - who represent train passengers in the UK.

Full size:File:SV-01 Rail Research UK RRUK Organisation Structure.jpg

Membership - Rail Research UK

Full size:File:SV-01 PassengerFocus Organisation.jpg

Describing Responsibility Extent or Jurisdiction

Describing System Structure

Tool Support

•

Sparx Enterprise Architect

Comments

Category:View
Category:Solution
Category:Structure
Category:Governance
Category:Membership

Concept Activity View

Purpose

Part of the TRAK Concept Perspective and one of the 21 TRAK views.

Describes what the node (thing) does. This provides a way of describing the overall concept in functional terms that are free of solution - i.e what it needs to do without the how.

Specification

Conforms to the CVp-05 Concept Activity Viewpoint

Tool Support

• Sparx Enterprise Architect

Applications or Uses

Comments

Category:View
Category:Operational
Category:Concept