View TRAK:System
Version & Date
28th January 2017
Configuration History
See change record for the TRAK metamodel at https://trakmetamodel.svn.sourceforge.net/viewvc/trakmetamodel/trunk/?view=log
Definition
One of the elements within the the TRAK metamodel and part of the Solution Perspective.
From the TRAK metamodel:
A composite structure exhibiting emergent behaviour.
Covered by TRAK IPR and licenses
Tests For
has feed- back/control mechanism via its parts that keeps it stable/opposes perturbations
Covered by TRAK IPR and licenses
Tests Against
- consists of Physical elements (with no behaviour)
- sum of functions of parts in configuration i.e.no emergent behaviour or properties
Covered by TRAK IPR and licenses
Attributes
Inherited Attributes:
- + from Architecture Description Element
- + from Resource (and hence also 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
TRAK::System has the following relationships with other TRAK metamodel elements:
- Physical contains System
- System realises Capability
- System is configured with Physical
- System is configured with Software
- System is configured with Human Resource (Organisation, Role, Job)
- System is configured with System
- Project Activity delivers System
- Project Activity removes System
- TRAK::System necessary for Project Activity
- Milestone marks introduction of System
- Milestone marks removal of System
Inherited relationships:
+ from Architecture Description Element
- Claim about System
- Concern about System
- Standard governs System
- Contract governs System
- Standard governs System
- System satisfies Contract
- System satisfies Requirement
- System satisfies Standard
- System traces to Argument
- System traces to Document
- System traces to Requirement
+ from Resource
- System performs Function
- Resource Interaction from System
- Resource Interaction to System
- System realises Node
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 https://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 INCOSE definition of a System is:
... an integrated set of elements, subsystems, or assem- blies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements.
Given the history of systems engineering and the origins in operational analysis where emergence, feedback and the notion of some form of control loop (not necessarily intentional) exists then this definition does no one any favours because it does not differentiate a System, and hence the need for Systems Engineering, from “stuff” - there is no need for emergence in this INCOSE definition nor the complexity that results.
TRAK makes the comment:
Can consist of purely human elements.
A system is stable and maintains itself this way - the constituent parts must therefore collectively provide the mechanism to keep the system stable. If an essential part of a system is removed it destroys that system (it might become a different system because the system boundary is then different). As ever “the whole is more than the sum of the parts”.
Covered by TRAK IPR and licenses
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
References
- TRAK. Implementation. Architecture Description Elements https://sf.net/projects/trak/files/Implement TRAK/
- INCOSE-TP-2003-002-004 INCOSE Systems Engineering Handbook v. 4. 2015 https://www.incose.org/ProductsPubs/products/sehandbook.aspx
- TRAK Enterprise Architecture Framework Metamodel. https://sf.net/p/trakmetamodel
Category:Metamodel -> Stereotype
Category:Solution