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

IEE1471/ ISO/IEC 42010: An architectural description is a model of the architecture; its purpose is to answer all identified stakeholders questions about all identified architecture-related concerns for the system of interest;

The collection of architecture products that describes a system of interest.

Covered by TRAK IPR and licenses

Tests For

Tests Against

Attributes

• approval authority
• architect
• assumptions and constraints
• purpose
• recommendations
• summary of findings
• tools used
• views

Inherited attributes:

+  from Architecture Description 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

Architecture Description participates in the following relationships:

• Architecture Description has part Architecture View
• Architecture Description has part Architecture Tuple
• Architecture Description is a Architecture Product

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

Master Architecture View

Any Architecture Description used within an architecture description(!!) of the system-of-interest must appear on a MV-02 Architecture Description Design Record View for the architecture description.

The MV-02 is the Master Architecture View for Architecture Description.

Covered by TRAK IPR and licenses

Comments

The purists will not like it (self-references / infinite recursion) but it provides a useful means for describing the scope/results for an architectural task using the MV-02 Architecture Design Record.

Covered by TRAK IPR and licenses

Other Frameworks

• MODAF::Architectural Description

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

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

Full size: File:System.jpg

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

• 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

30th September 2011

Configuration History

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

Definition

Resource that is connected with people, their organisation and what they do. It is the generalisation of Organisation, Job and Role. Abstract.

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.

Attributes

Inherited Attributes:

• + from Resource

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

Full size: File:HumanResource.jpg

Human Resource participates in the following relationships:

• Organisation is a Human Resource
• Job is a Human Resource
• Role is a Human Resource
• Human Resource is a Resource

Inherited relationships:

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

It is abstract - it can never appear on a TRAK architecture view or viewpoint.

It is, however, used in the TRAK metamodel to represent the Sponsor and Stakeholder concerns.

Master Architecture Viewpoint

Not applicable - Human Resource can never be instantiated/used in any TRAK architecture view.

Covered by TRAK IPR and licenses

Other Frameworks

• MODAF::Human Resource
• NAF::Human Resource

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

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

Part of the Solution Perspective.

A position of employment - usually but not always paid.

Covered by TRAK IPR and licenses

Tests For

• title on an organisation chart

Covered by TRAK IPR and licenses

Tests Against

• sounds like a responsibility

Covered by TRAK IPR and licenses

Comments

Jobs usually have many roles.

Attributes

• job holder name

Inherited Attributes:

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

Full size:File:Job.jpg

Job participates in the following:

• Organisation has part Job
• Job is a Human Resource
• Job governs Job
• Job plays Role
• System is configured with Job

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

Master Architecture View

Any Job 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 Job.

Covered by TRAK IPR and licenses

Other Frameworks

• MODAF::Post Type and MODAF::Actual Post
• NAF::Post Type and NAF::Actual Post

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

Part of the Solution Perspective.

An aspect of a person or organisation that enables them to fulfil a particular function.

Covered by TRAK IPR and licenses

Tests For

• many roles map to a single job

Covered by TRAK IPR and licenses

Tests Against

Attributes

Inherited Attributes:

• + Human Resource

Covered by TRAK IPR and licenses

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

Full size:File:Role.jpg

Role participates in the following:

• Organisation plays Role
• Role is a Human Resource
• Job plays Role
• Role requires Competence
• Role extends to Resource (System, Physical, Software, Human Resource)
• System is configured with Role

Configuration History

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

Comments

Jobs usually have many roles - some will be specific to the job and some will be more generic, for example as an employee. If a single role occupies most of the time of an employee then it is likely that a Job will be created around that role.

Sponsor and Stakeholder are roles that occur frequently and ISO/IEC 42010 / IEEE 1471 uses them in the definition of architecture viewpoints. A method for the use of TRAK:Role in a MV-02 Architecture Design Record is provided in the MVp-02 commentary which allows the scope and concerns of a particular architectural task to be described.

Typical roles include:

• Bidder
• Control Authority
• Design Authority
• Independent Safety Authority
• Prime Contractor
• Supplier
• System Authority

Master Architecture View

Any Role 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 Role.

Covered by TRAK IPR and licenses

Other Frameworks

• MODAF::Role
• NAF::Role

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

Part of the Solution Perspective.

An organised body of people, associated for a particular purpose.

Covered by TRAK IPR and licenses

Tests For

• concrete
• well- defined structure wrt parts and membership

Covered by TRAK IPR and licenses

Tests Against

• abstract

Covered by TRAK IPR and licenses

Attributes

Inherited Attributes:

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

Full size:File:Organisation.jpg

Organisation participates in the following:

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

 

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

An organisation can range in scale from something as large as a company or trade body to something as small as a team.

Tangible collection - you can touch the people (you can’t touch a project)

There are many different types of relationship that organisations can have and therefore TRAK can represent both membership, say of a trade body, and governance, say of a subsidiary. Membership is not the same as being part of another organisation - this is reserved for a component part of the organisation.

Master Architecture View

Any Organisation 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 Organisation.

Covered by TRAK IPR and licenses

Other Frameworks

• MODAF::Organisation Type and MODAF::Actual Organisation
• NAF::Organisation Type and NAF::Actual Organisation

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

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

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

Full size: File:Physical.jpg

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

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

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

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

Full size: File:Resource.jpg

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

30th-Sept-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 Management Perspective.

From the TRAK Metamodel:

An individual architecture description object that is used to describe or represent an item of real-world architecture. An architecture description element can appear in an architecture description.

Covered by TRAK IPR and licenses

Tests For

Not applicable - not itself used in any TRAK architecture views.

Tests Against

Not applicable - not itself used in any TRAK architecture views.

Attributes

• name
• description
• element URI
• AD exchange element external reference
• AD exchange element owning ID
• AD exchange element owning organisation
• AD exchange element recipient element name
• AD exchange element recipent element ID
• AD exchange element recipient organisation
• AD exchange element reference URL
• pm codeword
• pm descriptor (enumerated = None/Budget/ Commercial / In Confidence/ Investigation / Management /Medical / Personal /Personal Data/ Policy & Strategy)
• pm marking (enumerated = Not Protectively Marked /Protect / Restricted/Confidential / Secret /Top Secret)
• pm marking owner (organisation)
• pm national caveat
• reference URL

Covered by TRAK IPR and licenses

These attributes are intended to capture the information that might be needed for an exchange of an AD between 2 different organisations and therefore between 2 different tools.

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

Configuration History

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

Master Architecture View

Not Applicable since Architecture Description cannot itself appear in any architecture view - it is an abstract parent type or class.

Comments

The parent of all TRAK element types used in ADs. The intent of the attributes is to capture identification and ownership to allow bi-directional exchange of ADs between 2 organisations.

Covered by TRAK IPR and licenses

Element URI

The idea or thought is that someday it will be possible for models to be distributed and the URI is the attribute that holds the address of the element.

AD Exchange

Attributes beginning with ‘model exchange’ are designed to try and preserve information such that a 2-way round trip exchange of elements is possible between 2 organisations and therefore possibly tools. In this situation we need to try and preserve each organisation’s unique IDs etc.

Protective Markings

For the security-conscious it is now possible to declare national security classifications without the document becoming Restricted in doing so.  In the UK the Security Policy Framework replaces the older Manual of Protective Security (MPS). See http://www.cabinetoffice.gov.uk/spf/faqs.aspx on the Cabinet Office website.

The protective or protective markings are taken from the UK but should suffice in most situations, including commercial.

pm Descriptor

A qualifier used with the protective marking to denote the type of information, sensitivity or need to protect e.g. Personal. Commercial. i.e. combination might be PROTECT - PERSONAL

• None
• Budget - Proposed or actual measures for the Budget before their announcement
• Commercial - relating to a commercial establishments processes or affairs
• Indicates information received under an air of confidence, the disclosure of which might be an actionable breach in law
• Investigation - Investigations into disciplinary or criminal matters
• Management - policy and planning affecting the interest of groups of staff
• Medical - medical reports, records and material relating to staff
• Personal - Information that contains personal information of an individual. Material intended for the person to whom it may be addressed
• Personal Data - Any biographic data relating to an individual (e.g. name, address, D.O.B.) or Sensitive personal data as defined by s2 of the Data protection Act, including records relating to the criminal justice system, finances or group membership
• Policy / Strategy - information that forms part of a council policy or strategy or procedure that isassociated with internal use only

These have been taken from the following but the suspicion is that there is a Home Office or Cabinet scheme. Although UK in origin they do offer a general method for marking privacy even in non national security environments.

• Security Policy No.2: Protective Marking and Asset Control http://www.cabinetoffice.gov.uk/spf/sp2_pmac.aspx
• Handling of Protectively Marked Materiel - A Guide for Police Personnel (October 2001). http://www.ncalt.com/documents/modelsforlearning/Protective Marking.pdf
• Guidance for the Classification Marking of NHS Information http://www.connectingforhealth.nhs.uk/systemsandservices/infogov/security/risk/infoclassifications.doc
• The Use of Protective Markings in the Department of Work and Pensions. http://www.whatdotheyknow.com/request/14130/response/38437/attach/6/The Use of Protective Markings in DWP.doc
• Scottish National Infrastructure - Protective Marking Guideline http://www.improvementservice.org.uk/library/download-document/2342-scottish-national-infrastructure-guideline-for-protectively-marking-information/

pm Marking Owner

The owner of the protective marking who has the authority to sanction release or lower the protective marking classification. It is used in conjunction with the protective marking, usually as the prefix e.g. NHS PROTECT, TFL CONFIDENTIAL, or as a national authority - UK RESTRICTED.

pm Codeword

A codeword is another mechanism to limit distribution - only those with the need to know and the codeword have access to the element

pm National Caveat

A restriction of the audience who can see the element by nationality e.g. UK EYES ONLY would restrict the potential audience to UK nationals. This is not the same as the protective marking owner i.e. UK PROTECT does not restrict the audience and therefore the combination would be for example UK EYES ONLY, UK PROTECT

Note that a restriction on who can see the element through pm Codeword or pm National Caveat is separate to the marking itself. Similarly the release authority or owner is separate i.e. UK Protect means that the change of classification is with the UK authorities. This is not to be confused with UK Eyes Only which is a limitation on who can see the element.

Other Frameworks

References

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

Category:Metamodel -> Stereotype

Version & Date

27th-January-2011

Configuration History

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

Definition

A task which results in the delivery of one or more architecture products (architecture description, TRAK::architecture view, TRAK::architecture viewpoint, architecture framework).

Covered by TRAK IPR and licenses

Tests For

Tests Against

Comments

Used to help describe the scope and nature of the architecture task using the TRAK::MV-02 Architecture Description Design Record

Attributes

Inherited Attributes:

+ Architecture Description Element:

• finish date
• start date
• sponsor
• description
• stakeholder

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

Architecture Task participates in the following relationships:

• Architecture Task delivers Architecture Product
• Stakeholder sponsors Architecture Task

+ Architecture Description Element:

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

Master Architecture View

Any Architecture Task used within an architecture description of the system-of-interest must appear on a TRAK::MV-02 Architecture Design Record View for the architecture description.

The MV-02 is the Master Architecture View for Architecture Task.

Covered by TRAK IPR and licenses

Comments

Other Frameworks

References

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

Category:Metamodel -> Stereotype
Category:Management