View TRAK:System

TRAK_logo_60.jpg

Version & Date

28th January 2017

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 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:

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

System.jpg

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

Inherited relationships:

+ from Architecture Description Element

+ 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 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

 

 

Category:Metamodel -> Stereotype
Category:Solution

Categories:

 

© 2010 Eclectica Systems Ltd.