TRAK-Community

This is written from the viewpoint of delivering a high-integrity rail industry product by a company with globally dispersed engineering and production.

General
- UML/SysML is reaching a critical mass of acceptance as the architecture language in many areas of the international rail industry and whilst an industry architecture framework would be welcome, certain features of TRAK undermine that by seeming to include non-standard UML/SysML features.

The TRAK views:
- The TRAK views address functionality but do not seem to address non-functional issues, such as performance. This is a significant weakness, in view of the prevalence of performance specifications and contracts.
- Otherwise, the TRAK views provide a reasonable starting point for pilot use.

Language
- UML/SysML is internationally understood and standardised languages and this is a major advantage for internationally distributed projects. TRAK has introduced restrictions and divergences from standard usage. In effect, a local (GB) dialect is proposed and this will be a significant obstacle to international use. Examples follow, below.

- Activities that are stereotyped <<OperationalActivity>> seem to perform the same function as Use Cases in standard UML. Why? – for some organisations UCs are the well-established stock-in-trade method of defining the operational needs of high-integrity products and systems. The TRAK approach is confusing and precludes the use of features in tools designed to develop and managing Use Cases. For example, the new UC tools in EA v8.0 cannot be used on activities.

- In a similar vein, requirements created in EA from the MDG add-in are not recognised by the RaQuest add-in requirements traceability feature, but those created by the standard UML profile are recognised. The former is a special TRAK requirement and the latter is a standard UML requirement.

- The use of attributes and operations is inhibited. Why? These are valuable features and provide a mechanism for defining performance (the use of SysML parameter diagrams is another).

- The use of colour is squandered by its mandatory use in identifying TRAK entities. This precludes it use for project specific uses (such as identifying the supplier of an entity, etc).

Conclusion:
- Timely concept but implementation presents some issues.
- Use the full suite of standard SysML plus some standard UML (principally deployment diagrams). Use only standard UML / SysML.
- Don’t use colour to indicate standard TRAK stereotypes.
- Add non-functional requirements views, particularly performance views.
- Use the existing framework of views for pilot use and re-assess after experience has been gained.

Thanks SE Pro for taking the time and interest in TRAK to respond. Many don’t and the whole point in making TRAK open source is to tap the experience of those like yourself to improve it.

SE Pro - 15 March 2010 05:20 PM

This is written from the viewpoint of delivering a high-integrity rail industry product by a company with globally dispersed engineering and production.

General
- UML/SysML is reaching a critical mass of acceptance as the architecture language in many areas of the international rail industry and whilst an industry architecture framework would be welcome, certain features of TRAK undermine that by seeming to include non-standard UML/SysML features.

Agree with the first part. The second statement about TRAK isn’t true.

TRAK is an enterprise architecture framework NOT a presentation language. TRAK provides a set of object types and relationships. TRAK, like DODAF, MODAF et al is completely independent or agnostic of the language/notation you wish to use whether UML, SysML, BMPN, IDEF0 or whatever the language of your choice is. It does not therefore mandate that you use any particular modelling language, only that you ‘type’ your objects and use only the ones that TRAK supports. You need to separate the two - TRAK allows you to use BPMN to, say, create a SV-04 Solution Functionality View. You could use UML - both would be TRAK compliant providing you have the TRAK constructs.

The other point to be aware of is the need to separate the definition of TRAK - logical - from any implementation. This is important because each tool introduces its own problems or limitations - these ARE NOT a TRAK problem as such. In other words if there is a problem in a tool it could well be the tool or the implementation of TRAK for the tool rather than TRAK itself. You could, if you were a masochist, sketch a TRAK compliant view or architecture description in pencil on paper.

SE Pro - 15 March 2010 05:20 PM

The TRAK views:
- The TRAK views address functionality but do not seem to address non-functional issues, such as performance. This is a significant weakness, in view of the prevalence of performance specifications and contracts.
- Otherwise, the TRAK views provide a reasonable starting point for pilot use.

Not true. This is a question of how you represent non-functional areas. These are normally constraints and therefore in TRAK you would have attach the non functional requirement to the Resource (System, Physical, Organisation, Role, Job). You can then add a Metric with the specific - in this case - performance measure. This is what the OV-07 Operational Constraints and SV-10 Solution Constraints Views are provided for. In other words the construct is either : thing - Requirement, or Function - Metric and Function - Requirement. It is likely that Metric will be able to be attached to anything - this is under review. In addition to this you also have attributes.

If you’re not using functions, things or requirements how do you represent a non-functional ‘issue’? What is an issue? A shortfall or gap in requirement, function or design - if so these are covered as above. If it is an ‘issue’ TRAK provides an object called ‘Concern’ that you can attach to anything in the model.

Have you looked at the attributes of the objects? You’ll find, for example, that Function, Resource inherit Safety Integrity Level etc. You are free to add attributes to objects - TRAK itself specifies a minimum common core but allows you to have your own set. The risk in doing so is that you may not be able to exchange your model with another organisation or have problems in mapping what you’ve used against the way they’ve done it.

SE Pro - 15 March 2010 05:20 PM

Language
- UML/SysML is internationally understood and standardised languages and this is a major advantage for internationally distributed projects. TRAK has introduced restrictions and divergences from standard usage. In effect, a local (GB) dialect is proposed and this will be a significant obstacle to international use. Examples follow, below.

Not true. As above - TRAK does not specify UML/SysML and by definition therefore cannot impose any divergence. In EA (and presumably other UML modelling tools) you can in fact add the SysML stereotype e.g. <<block>> to class-like elements such as Resource, Node etc and create TRAK-compliant views using SysML. I’ve cheerfully created TRAK views using SysML in EA. Can you identify what tool + version you’re using?

The ‘GB dialect’. Can you please specify what it is in TRAK that is GB-specific? As far as I can see we only have general concepts like System, Function etc. which are universal. Indeed although it started off in rail there aren’t any rail or any other industry constructs - deliberately so because TRAK represents systems and they don’t know what industry they’re in. It is in English and therefore anglo-centric but I don’t have the skills to make it otherwise:down: The only other UK construct might be privacy markings.  Some justification of ‘GB dialect’ is therefore needed.

SE Pro - 15 March 2010 05:20 PM

- Activities that are stereotyped <<OperationalActivity>> seem to perform the same function as Use Cases in standard UML. Why? – for some organisations UCs are the well-established stock-in-trade method of defining the operational needs of high-integrity products and systems. The TRAK approach is confusing and precludes the use of features in tools designed to develop and managing Use Cases. For example, the new UC tools in EA v8.0 cannot be used on activities.

Confused. You accuse TRAK of not using standard UML but UML has both Activity and Use Case - this is because one isn’t the same as the other in UML. A UML::Use Case is a description of a scenario, not a single activity (http://en.wikipedia.org/wiki/Use_case). None of this has anything to do with TRAK - it’s in the definition of UML and SysML. TRAK uses UML::Activity to represent TRAK::Operational Activity in the UML notation (see above). This seems to be entirely reasonable and therefore a pretty standard way of representing an activity.

You could, I suppose, have approximate a UML use case using a broad activity (Operational Activity, Function) broken down into small activities (but beware because the System is not by definition the sum of its Functions). In any case if all you want the Use Case for is to show a relationship between UML:Actor and UML:Use Case you can achieve the same thing by a relationship between a TRAK::Human Resource (Organisation, Job, Role) and TRAK::Function or you can link TRAK::Role via extends to and then Resource or add Competence to perform Function so TRAK isn’t short of ways of linking actor-like things to Function. I do, again, need to re-iterate that TRAK does not attempt to replicate the set of diagrams present in UML or SysML. If you want to stick to UML or SysML, do so. They are pretty good. What TRAK (MODAF, DODAF et al) do is restrict the set of building blocks so that you can exchange, re-use or collaborate on models with anyone else.

SE Pro - 15 March 2010 05:20 PM

- In a similar vein, requirements created in EA from the MDG add-in are not recognised by the RaQuest add-in requirements traceability feature, but those created by the standard UML profile are recognised. The former is a special TRAK requirement and the latter is a standard UML requirement.

You need to be clearer. What is the ‘standard UML profile’? In the MDG add-in for Sparx Enterprise Architect, itself based on the UML profile for TRAK, TRAK::Requirement is defined as extending UML::Requirement. It does so to add extra attributes wrt priority et al that are often used. Again this is totally standard. This looks to be a tool problem and on RaQuest to understand what’s happening.

SE Pro - 15 March 2010 05:20 PM

- The use of attributes and operations is inhibited. Why? These are valuable features and provide a mechanism for defining performance (the use of SysML parameter diagrams is another).

Not true. Again, TRAK itself doesn’t care. In what tool? Are you using the beta version of EA 8 - the one identified as not to be used for production? It seems to work in EA 7.5 and others. There is nothing inherent in the UML profile for TRAK or the MDG plugin for Sparx EA that has this behaviour or restriction. Again, this sounds like a tool problem. The TRAK stereotypes themselves have attributes (expressed as tagged values) for this very reason - they are useful. Can you confirm what tool and version this appears in? Although I have the beta version 8 of Sparx EA I daren’t use it just in case it adds something to the database that can’t be undone.

SE Pro - 15 March 2010 05:20 PM

- The use of colour is squandered by its mandatory use in identifying TRAK entities. This precludes it use for project specific uses (such as identifying the supplier of an entity, etc).

This is exactly what TRAK sets out to do. TRAK is a standardisation effort. It is an interoperability standard. As with all standardisation it imposes constraints. It does so because we want models to be able to transfer between projects, organisations and not only the model but the meaning. Colour in TRAK is an important piece of this - it helps spot errors, you can immediately tell which Architecture Perspective you’re in etc. Without this everyone, every project, every company has their own unique colour scheme and it soon gets to be very confusing. You can, of course, add an image to any element.

SE Pro - 15 March 2010 05:20 PM

Conclusion:
- Timely concept but implementation presents some issues.
- Use the full suite of standard SysML plus some standard UML (principally
deployment diagrams). Use only standard UML / SysML.

There is no non-standard UML in TRAK whatsoever. It would have been nice to base an implementation on the SysML profile instead of UML but Sparx EA 7.X won’t allow profiles to be based on anything other than UML.

Who said you can’t use deployment diagrams? TRAK makes no restriction nor do any of the implementations. If you want to you can - they take the same form as the class diagrams i.e. the same restrictions in terms of types of object allowed for each TRAK architecture view apply to instances as to their parent classes.

SE Pro - 15 March 2010 05:20 PM

- Don’t use colour to indicate standard TRAK stereotypes.

Disagree.

SE Pro - 15 March 2010 05:20 PM

- Add non-functional requirements views, particularly performance views.

Already have these. OV-07 & SV-10.

SE Pro - 15 March 2010 05:20 PM

- Use the existing framework of views for pilot use and re-assess after
experience has been gained.

As we will continue to do so. This is far from a static affair. It is something that evolves in frequent small micro steps rather than large infrequent seismic changes - witness today with privacy marking attributes added to Architecture Element.

Thanks for your feedback

SE Pro - 15 March 2010 05:20 PM

This is written from the viewpoint of delivering a high-integrity rail industry product by a company with globally dispersed engineering and production.
This precludes it use for project specific uses (such as identifying the supplier of an entity, etc).

Sorry, missed this one the first time around. Colour isn’t much use if you want to trace something - it needs to be a relationship that can be queried in the underlying database.

In TRAK you have constructs which are standardised and can subsequently be traced in a tool (colour can’t) to show this sort of thing:

* <<Organisation>> Your Company —plays—> <<Role>>Supplier —extends to—> <<Resource>> Thing

or you could have Sponsor, System Design Authority, Control Authority, Movement Authority etc.

and don’t forget that TRAK can be used to model both the technical solution (the thing being supplied) as well as the business that produces it. You’d be hard pressed using colour to get the distinctions possible in TRAK such as membership, governance, part etc.

An indication of the range of possibilities using the SV-01 Solution Structure View is provided externally - this shows some of the constructs - you wouldn’t normally mix product structure with responsibility or governance as views need to have a clear subject.

The beauty of a repository and the longevity therein is in the exploitation of the underlying relationships by the tool (or by an external SQL tool) - not the visual dressing. For this you need consistency though otherwise my queries won’t work with your models and vice versa.

Well, that told me! Thank you, Wikitect for your extensive replies, which I will study in detail.

They expose an important point. I’ve spent a considerable number of years in system engineering, a similar number of years practical experience of using UML/SysML and far too long in engineering in general. I have to get an understanding of complex engineering documents very quiickly. I spent the best part of a day making an initial assessment of TRAK (and that is a long time in today’s hard-pressed world) and yet I misunderstood so many things. I have spoken to colleagues who have a similar engineering background and who have similar misunderstandings.

The message is that there must be a clearer overview of TRAK, because rapid and easy understanding is key if potential users are not to put it to one side until client push forces them to use it.

You don’t need to convince me (one of the converted) that an architectural framework is a good thing, particularly in a globally-spread organisation, but you do need to convince the unconverted non-specialist engineer and budget holder, to whom systems thinking is a foreign land and to whom the very real costs of training and roll-out and compatibility with legacy work figure strongly.

There should be a twin focus to TRAK work, supplementing work on the technical subleties with development of a clearer understanding of the benefits and basic concepts. The content of your replies would go some way towards the latter.

I have tried the TRAK MDG add-in and the UML profile on both EA 7.5 and 8.0 beta2. I am also aware of most of the explanations of UML/SysML and EA capability that you mentioned in you replies and do not spend time referring to them below or to a number of minor issues. I was not aware that EA did not allow profiles based upon SysML.

1. The most important clarification in your replies was that “…TRAK does not specify UML/SysML…” (or any other language).  I had gained the impression that in this case and in the interests of standardisation, both the framework and the language was specified, and a restricted set of the language at that.

2. Performance: I am aware of the potential to use constraints and attributes and they can be added to entities created by the MDG add-in (in fact, the use of attributes in this way is consistent with the recommendations of the discontinued IEC prR009-003 “Guide to the specification of a guided transport system”). My description of difficulties with attributes was unclear: although I found that they could be added and were held in the repository database, their display on diagrams was inhibited. To me, this is a significant disadvantage with a graphical methodology. My desire is to use SysML parameter diagrams to help define performance and assume that your response regarding deployment diagrams applies equally to parameters diagrams, too.

3. Use Cases: I am aware of the differences between activities and use cases. I gained the impression from the TRAK examples that <<Operational Activities>> were being used as quasi-use cases, and was unclear why use cases themselves were not used. In the absence of use cases, the mechanism for scenario definition is unclear – can you clarify? Without the use cases, the benefits of tool features for use case processing is also lost. Although you explain work-arounds (e.g. HR – Function relationship, etc) I am still strongly of the opinion that exclusion of use cases is a major omission and restriction, not least upon productivity and industry familiarity.

4. Colour: I am aware that colour is not a traceability mechanism. TRAK recognises that colour is a useful means of visually identifying (stereo)types of entity groupings, exceptions, etc. The point I was poorly making was that use of colour for this purpose prevents its use for other purposes – such as, for example, identifying entities by supplier, or by project migration phase, etc, etc. These are valuable features during implementation. I can quite see the advantages of the TRAK approach to colour but, since it colour codes standard stereotypes, it is a less valuable use than stereotyping non-standard or changing aspects of the system.

5. Standardisation: standardisation provides advantages and disadvantages but the value of these depend on the viewpoint of the user. The use of colour and the exclusion of use cases are examples. Read my lips: I completely support the development of TRAK. However, I am concerned that it does not make life easier for some sections of the client – supplier chain at the expense of others. It must suit the vast majority of users over the vast majority of the lifecycle. No process developer can foresee the needs or all users and a degree of flexibility is essential. Excessive straight-jacketing could lead to one framework being used for, say, client purposes and another for implementation. This must be avoided at all costs.

6. Cheerfulness: You stated that you’ve “…cheerfully created TRAK views using SysML…” I am particularly interested to learn more about any tips you may have on remaining cheerful during such activities, as I have always had considerable difficulty in this area, but then I am an old git.

It happens to us all at some point or other.

Clearly interested to find out what, if any, foibles EA 8 beta introduces as feedback to Sparx will be needed.

The confusion between a framework requirements wrt views and SysML or UML is a common one. We do intend to add ways of providing some general information. Some of this can be put into a FAQ - each site on Sourceforge has this. It is also worth using the support tracker for specific help.

We do have quite a lot of other introductory documentation generated over the last year but it’s a question of time and the best mechanism and place to hold this. As some of this is owned by London Underground Limited they’d need to sanction its release. I’ve developed a CONOPS for TRAK as a whole which provides the aims, direction and identifies how things are intended to be managed. I also have a model (using TRAK!) of this.

Some of this isn’t, however, a framework thing. Even if we had the most prescriptive framework in the world (we don’t I hasten to add) you would still get differences in modelling style which would affect how you represent situations. Architectural modelling isn’t a precise science - it’s a highly creative and artistic activity. This can partly be addressed by providing applications of TRAK use in day to day contexts. I have an application section in the wiki on this site for that and am hoping that others might contribute (as otherwise I’m the point of failure / critical path and everything on this site is done in ‘spare’ time - difficult whilst trying to set up, generate content, structure and tackle presentation at the same time). Out of this I hope that there might be some architecture description design patterns.

The best advice if you’re using Sparx EA is to use the Quicklink feature and quickly knock up some views. There are some examples within the Template Model provided (also available separately at http://sourceforge.net/projects/mdgfortrak/files/ and also on some of the TRAK viewpoint descriptions in the wiki.

The real emphasis behind TRAK is
* providing pragmatic views around typical systems-thinking/engineering topics/concerns
* providing a means for the different disciplines to discuss the system design
* providing a controlled set of modelling elements (= language) such that you can exchange, collaborate and re-use architecture models. I’m also trying to aid this through providing a registry = discovery service for models.

There are some important concepts and it does take a while to get your head around. You have to think big i.e. a virtual or real repository (whether central or distributed) with thousands of models which everyone is working on or using - not just something local. Hence the need for standardisation and interchange standards.

I’ll bite this off into chunks - it might take a while to fit this into the day job…

SE Pro - 16 March 2010 01:08 PM

I have tried the TRAK MDG add-in and the UML profile on both EA 7.5 and 8.0 beta2. I am also aware of most of the explanations of UML/SysML and EA capability that you mentioned in you replies and do not spend time referring to them below or to a number of minor issues. I was not aware that EA did not allow profiles based upon SysML.

1. The most important clarification in your replies was that “…TRAK does not specify UML/SysML…” (or any other language).  I had gained the impression that in this case and in the interests of standardisation, both the framework and the language was specified, and a restricted set of the language at that.

2. Performance: I am aware of the potential to use constraints and attributes and they can be added to entities created by the MDG add-in (in fact, the use of attributes in this way is consistent with the recommendations of the discontinued IEC prR009-003 “Guide to the specification of a guided transport system”). My description of difficulties with attributes was unclear: although I found that they could be added and were held in the repository database, their display on diagrams was inhibited. To me, this is a significant disadvantage with a graphical methodology. My desire is to use SysML parameter diagrams to help define performance and assume that your response regarding deployment diagrams applies equally to parameters diagrams, too.

SE Pro - can you please be careful when trying and failing to do something in a tool to establish the true cause of this rather than simply assume that it is something to do with TRAK? It makes it very hard to separate out what might be a genuine problem with TRAK from what in this case is “finger trouble”.

This is nothing to do with TRAK!! The visibility of attributes on diagrams within Sparx EA is an entirely EA property that is controlled by a combination of a) diagram properties and b) model element properties. If you right-click on the object (or set of objects) and select Feature Visibility you should then have the opportunity to choose what is shown.

SE Pro - 16 March 2010 01:08 PM

6. Cheerfulness: You stated that you’ve “…cheerfully created TRAK views using SysML…” I am particularly interested to learn more about any tips you may have on remaining cheerful during such activities, as I have always had considerable difficulty in this area, but then I am an old git.

Not the only one! I’m a user not a theoretician - having spent 30 years in systems engineering and probably 6 years of that on architectural modelling (and a good while at both Abbey Wood and the Architectures Lab at Malvern). I have the scars and experienced what works and what doesn’t - both from a specification and a working process perspective.

SE Pro - 16 March 2010 01:08 PM

4. Colour: I am aware that colour is not a traceability mechanism. TRAK recognises that colour is a useful means of visually identifying (stereo)types of entity groupings, exceptions, etc. The point I was poorly making was that use of colour for this purpose prevents its use for other purposes – such as, for example, identifying entities by supplier, or by project migration phase, etc, etc. These are valuable features during implementation. I can quite see the advantages of the TRAK approach to colour but, since it colour codes standard stereotypes, it is a less valuable use than stereotyping non-standard or changing aspects of the system.

I didn’t say I was going to follow the order presented!

In my reply:

wikitect - 15 March 2010 10:14 PM

SE Pro - 15 March 2010 05:20 PM

This is written from the viewpoint of delivering a high-integrity rail industry product by a company with globally dispersed engineering and production.
This precludes it use for project specific uses (such as identifying the supplier of an entity, etc).

Sorry, missed this one the first time around. Colour isn’t much use if you want to trace something - it needs to be a relationship that can be queried in the underlying database.

In TRAK you have constructs which are standardised and can subsequently be traced in a tool (colour can’t) to show this sort of thing:

* <<Organisation>> Your Company —plays—> <<Role>>Supplier —extends to—> <<Resource>> Thing

or you could have Sponsor, System Design Authority, Control Authority, Movement Authority etc.

and don’t forget that TRAK can be used to model both the technical solution (the thing being supplied) as well as the business that produces it. You’d be hard pressed using colour to get the distinctions possible in TRAK such as membership, governance, part etc.

The beauty of a repository and the longevity therein is in the exploitation of the underlying relationships by the tool (or by an external SQL tool) - not the visual dressing. For this you need consistency though otherwise my queries won’t work with your models and vice versa.

you’ll see that TRAK can represent the connection, in your case, of supplier to equipment using a relationship between model elements. It can therefore be discovered (traversed or navigated by).

If the capturing of Supplier is important then it doesn’t seem sensible to rely on colour - it’s easily lost and your scheme is easily overwritten or might clash with someone else’s use of colour. Much better to hard-wire it in using a systematic construct based on relationships.

Similarly if you want to show the connection of System to a Project then you’d use the PrV-02 Procurement Timeline to show what System is being introduced or removed by what project and when. It also allows you to show dependencies between projects.

There is clearly some adjustment here. You’re used to using colour whereas TRAK provides relationships between the elements to achieve the same utility. The advantage of the TRAK method is it joins all the different perspectives (Capability, Operational, Procurement, Solution) together in a way that colour can’t. Worth looking at the simplified TRAK metamodel to see this (also added to Wikipedia as a fragment - not a controlled copy).

The point is because TRAK handles these relationships by providing tangible relationships (!) - you don’t need colour to do this. There are a lot more combinations and flexibility inherent in using objects and relationships than is possible using colour. You can define any Role, by any Organisation and connect the Role to any number of combinations of Resource. And the meaning is explicit by reading the Object - relationship - Object “sentence” - no key or legend needed.

SE Pro - 16 March 2010 01:08 PM

3. Use Cases: I am aware of the differences between activities and use cases. I gained the impression from the TRAK examples that <<Operational Activities>> were being used as quasi-use cases, and was unclear why use cases themselves were not used. In the absence of use cases, the mechanism for scenario definition is unclear – can you clarify? Without the use cases, the benefits of tool features for use case processing is also lost. Although you explain work-arounds (e.g. HR – Function relationship, etc) I am still strongly of the opinion that exclusion of use cases is a major omission and restriction, not least upon productivity and industry familiarity.

There are at least 2 important points here:

1) TRAK (or any other framework) isn’t SysML or UML and there’s no point in replicating it. They have different but complementary uses and there are subtleties therein. In UML you’re not primarily concerned with exchange of your model - it’s a tool to help define, explore, elucidate etc. Equally, and this comes through from the UML modelling tools, relationships between objects are less important that the objects themselves and their attributes and behaviours. In enterprise architecture we’re trying to establish what are objects with a commonly agreed type, and definition - an object dictionary complete with relationships such that anyone can use them, exchange, identify interfaces (relationships with). It is far more community and relationship-oriented than traditionally the case. If we don’t we’re in the current state where things are only done on an individual basis, every model is unique, definitions don’t travel etc.

2) As it isn’t SysML you shouldn’t throw up your hands in horror simply because it doesn’t have what you’re used to using in SysML. Yes it might be out of the comfort zone but in EA we’re trying to get people to have a few types of object but combined consistently in many ways i.e. it’s always the combination of 2 or more types with relationships that provides the meaning. This provides much more flexibility and richness than you think and it maximises the chances of re-use of models/model elements - a significant cost to the business.

3) TRAK can describe behaviour, it can describe associations, dependencies and you can use activity or state diagrams if you so wish. You can associate a System, Organisation, Job, Role, Software or Physical thing with behaviour and you can attach constraints via Requirements. What more do you want? In a Use case what are the object types and where would they fit? A Function (activity) isn’t a Use Case. The point is that the relationships in TRAK are standardised in terms of type and name and properties. What is an Actor? In TRAK terms it would either be a Resource or in the logical (operational) area it would be Node. You can associate these with behaviour and with exchanges of information, energy and materiel.

As far as requirement analysis is concerned the implementation of TRAK::Requirement contains is an extension of a UML::Requirement and should therefore work nicely with the bridge between DOORS so that requirements can be linked to model elements.

One last point not mentioned. In TRAK we’ve gone to some trouble to keep things simple and to insist that relationships have an easily read label. Anyone should be able to read the views as a result - you don’t have to be a SysML, UML or what-ML expert to understand - this is important if you’re trying to communicate with others such as programme or commercial managers (bearing in mind that TRAK covers all sorts of areas from strategy downwards). Do you use UML or SysML to show senior management or non engineers how your solution fits in with the bigger picture? I doubt it and I bet that’s done in something else.

It might not be perfect and it is meant to supplement rather than replace other things in your toolkit but TRAK provides a far broader scope as it is intended to help more than just the conspicuous discipline / system engineers (SE ought to be being done by everyone to different degrees).

As I said before you can supplement TRAK with whatever you want. If you feel you need use cases do so - they just cannot be in a model that is TRAK-compliant. Can you provide an example of a use case?

SE Pro - 16 March 2010 01:08 PM

5. Standardisation: standardisation provides advantages and disadvantages but the value of these depend on the viewpoint of the user. The use of colour and the exclusion of use cases are examples. Read my lips: I completely support the development of TRAK. However, I am concerned that it does not make life easier for some sections of the client – supplier chain at the expense of others. It must suit the vast majority of users over the vast majority of the lifecycle. No process developer can foresee the needs or all users and a degree of flexibility is essential. Excessive straight-jacketing could lead to one framework being used for, say, client purposes and another for implementation. This must be avoided at all costs.

As I’ve explained earlier the need to use colour to show a responsibility, structural or functional or project time boundary or role is handled in TRAK by pucker relationships - not left to the individual to make up. Standardisation is about having a common viewpoint not a local one. I can guarantee that your use of colour will be different to LUL, Network Rail and also within any company so it has no value if you want to move your model.

Similarly Use Cases as TRAK isn’t UML or SysML although you’re free to use these to create TRAK views.

It only seems to make like harder because it’s very unfamiliar - quite natural. I doubt that you’d appreciate subtleties or power in UML or SysML in a day and a bit.

I do object to ‘process developer’ since
* I’m a long time practising (one day I’ll get it right ) systems engineer/thinker - TRAK is very pragmatic and deliberately ‘good enough’
* unlike TOGAF, TRAK is not and does not mandate a process so this is technically incorrect

In any case TRAK is almost certainly the first open source architecture framework. If we’d wanted to be exclusive we wouldn’t have gone to the trouble of opening it up. The whole point of this is that anyone - including yourself - can get involved in the definition of TRAK. The whole thing is deliberately as inclusive as it’s possible to be - try this with SysML or any other standard. We have, for example, an ongoing assessment of the application of TRAK to Human Factors to see whether we need new views or whether it can be covered using variants of existing views. We will, however, keep things as simple and as small a set as is possible. More choice might look good but with it comes difference of opinion and selection and then you can’t join or exchange different models.

You might like to think of some FAQs - I’ve added a page to the wiki to capture these.

SE Pro - 16 March 2010 11:24 AM

Well, that told me! Thank you, Wikitect for your extensive replies, which I will study in detail.

They expose an important point. I’ve spent a considerable number of years in system engineering, a similar number of years practical experience of using UML/SysML and far too long in engineering in general. I have to get an understanding of complex engineering documents very quiickly. I spent the best part of a day making an initial assessment of TRAK (and that is a long time in today’s hard-pressed world) and yet I misunderstood so many things. I have spoken to colleagues who have a similar engineering background and who have similar misunderstandings.

The message is that there must be a clearer overview of TRAK, because rapid and easy understanding is key if potential users are not to put it to one side until client push forces them to use it.

As a starter towards this
* I’ve added a section at the front of the TRAK Viewpoints document that outlines some important ideas, what TRAK is and what it isn’t - would be good to get some feedback.
* I’m in the process of creating a page on the wiki titled ‘I Want to Represent ...’ to provide some ideas of how to represent common things using TRAK. This will supplement the application section where I’ve started to look at things like views that would support particular design reviews - I’ve started with the Critical Design Review