The following are answers to commonly answered questions about TRAK to date. If you have a question that isn’t in this list it would help to post it into the TRAK Community Forums at


I have the UML profile for TRAK - where is my UML or SysML ... diagram?


TRAK is a logical definition. It only specifies the types of objects and relationships allowed for each TRAK View(point). Like DODAF and MODAF it does not specify what presentation or notation language (an Architecture Description Language - ADL) you use to provide these views.

TRAK views are not therefore SysML, UML, BPMN, IDEF0 or anything-else diagrams - they are TRAK views and conform to:

Any architecture description language (ADL) may introduce its own artefacts and it may not be capable of representing all the object types or relationships within the TRAK metamodel. A modelling tool might also not implement the notation fully. This is common to any architecture framework e.g. the UML profile for MODAF and DODAF (UPDM) introduces constraints such as composite structure diagrams which are not a requirement of wither DODAF or MODAF.

The intent with TRAK is that any mappings between an ADL and TRAK are held centrally but not being part of TRAK are recorded in a document. There is a folder on the TRAK project on Sourceforge set up to hold these and to provide a template to make it easier for implementers:

TRAK Won’t Let Me Use My Colour Scheme and Therefore I Can’t Use it to Represent the Things I Need To

TRAK insists that you use the fixed colours it specified for objects if you’re not using a graphic. It does this a) for consistency and b) to make it easy to spot errors in a view.

The problem with using colours for anything more serious are:

  • every company, project etc. has their own colour scheme
  • you soon run out of colours
  • they don’t always transfer

TRAK says that meaningful information is recorded using relationships which do transfer and require no unique look-up table.

Often people want to denote “Company X’s” involvement with part of the architecture. What they often mean is that Company X plays a role with respect to .... In TRAK you’d represent this using on a PrV-03 view using the relationships:

You could then have a role of supplier, system design authority etc. for specific parts of your solution. See - Representing Responsibility Extent and Roles.

The advantage of using relationships is that they will export and you can use them within a modelling tool to navigate through the architecture description - you can’t do this with a colour.

Category: Help Category:Question Category:SysML Category:UML



© 2010 Eclectica Systems Ltd.