Page 4 of 4 pages ‹ First  < 2 3 4

A System is a System, Right? Not if You’re Head-Modelling

Introduction

Choosing stereotypes for an enterprise architecture framework isn’t easy. In defining something you embed the prevailing view at the time the framework was created. This may later haunt you. With every extra stereotype you add choice and then when you add the poor old architect or modeller into the mix you increase the possibility of inconsistency - the very thing the metamodel is designed to constrain and eliminate. This is illustrated very nicely in trying to place ’System’ at the centre of TRAK.

Since we started with MODAF 1.2 this is where the story begins.

MODAF 1.2

In the MODAF System is defined as

The usage of an artefact as a System in a Capability Configuration

and part of the physical architecture.

MODAF::System - A Physical Artefact

Technically it is defined as an Artefact alongside Platform. This arose because when the MODAF was originally launched the consensus on what a system is wasn’t the currently accepted one with emergence et al and the MODAF quite reasonably took the then accepted view - hence it is a purely man-made thing. No notion of complexity whatsoever.

From the The MODAF System Viewpoint(SV) (17th February 2009):
‘Artefacts - Physical objects made for a purpose (e.g. system, sub-system, platform, component or any physical item that occupies space and has attributes)’

‘Physical Architectures - Configurations of resources for a purpose (e.g. capability configurations)’

‘The physical resources contributing to a capability must either be an organisational resource or a physical asset. That is, a system cannot contribute alone; it must be hosted on a physical asset used by an organisational resource of both. Organisational aspects (e.g. who uses a system) can now be shown on SV-1.’

In short as it is defined in MODAF 1.2:

• system is something physical
• it is man-made
• it can’t contain anything else like Organisation, Post or Role, or Software
• it is not the same thing as a Capability Configuration
• systems cannot provide capability

TRAK

When creating TRAK we found we couldn’t use MODAF::System as it didn’t fit with either the London Underground view of a system or the INCOSE or ISO ones.

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

It was therefore impossible to use MODAF::System to represent what is currently accepted to be a system. So what could we use? As a system is a mixture of hard and soft resources it made sense to position at the centre of TRAK:

TRAK::System - Central to the Metamodel

Immediately therefore this allows us to describe systems

• composed of a mixture of equipment, software and people - not just physical
• composed of just software or of just human stuff - soft systems

and we don’t need ‘Sub-system’ either or ’System of Systems’ since the terms just reflect a point of view in the hierarchy of systems and we already have the construct ‘System is configured with System’ to allow us to represent systems at any level. In fact if we introduced sub-system we would be forcing architects to make a choice and with choice comes difference of opinion and the potential for inconsistency - my Sub-system might be your System and so on.

Now Add People

The choice of metamodel elements is important, particularly when you add people (users of the metamodel) into the mix.

Some of you will be looking at the TRAK metamodel fragment above and thinking ... Capability Configuration. Indeed in MODAF this is where Capability Configuration sits. So is Capability Configuration correct? As defined it cannot be - Capability Configuration is still part of the Physical Architecture.

The bigger problem, however, is that you end up using one element but with the meaning of another. It’s easy to see how this might arise - being not allowed to add parts to MODAF::System the architect takes the stereotype that does allow him or her to add the stereotypes that they want - the Capability Configuration. It is possible that they don’t even see the problem in doing so. The trouble is that they describe something as a system but use Capability Configuration. Their ‘head-model’ doesn’t fit the meaning of the model elements used.

It is actually worse because in providing MODAF::Platform and MODAF::System there is a choice to be made - when is something a platform and when is it a system? You can almost guarantee that different choices will be made and therefore it makes it more likely that architecture descriptions (models) can’t be ported between organisations. In fact the poor modeller has 3 stereotypes that can be used to mean ’system’ (in their head) - the MODAF::Capability Configuration, MODAF::System and MODAF::Platform. On the receiving end you can’t predict which will have been used.

This is why in TRAK there is only 1 TRAK::System. It’s flexible, can be used for hard or soft systems and, importantly, ‘there shall only be one’ - no sub, super or whatever-system.

You describe the context simply by the system boundary and hierarchy. Easy.

After all a system is a system.

Acknowledgements

The MODAF is Crown Copyright/MOD
The TRAK Metamodel is released under the GNU Free Documentation License.

Comments

Comment on this article

OMG - Multiple tool vendors demonstrate exchange of UML models using XMI

From the Object Management Group (OMG) website:

OMG’s Model Interoperability Demonstration a Success
Multiple tool vendors demonstrate exchange of UML models using XMI

Needham, MA, USA - January 4, 2010 - Members of OMG’s™ Model Interchange Working Group (MIWG) held an Interoperability Demonstration on December 7, 2009 at the OMG Technical Meeting in Long Beach, California. This event demonstrated an initial capability to interchange UML® models between six tools from five different vendors. The participating vendor tools included Artisan Studio, IBM Rhapsody, IBM RSx, SOFTEAM Modelio, No Magic MagicDraw, and Sparx Systems Enterprise Architect. The MIWG has posted a recording of the demonstration, as well as an introductory presentation at http://www.omgwiki.org/model-interchange/doku.php.

During the demonstration, the test conductor provided a reference diagram to the participating vendors that they had not previously seen. Each participating vendor used their tool to create a diagram that was intended to replicate the reference diagram, and then generate and export the corresponding XMI to a shared work area. The participating vendors then used their tool to import the XMI® created in the other tools, and regenerate the diagram.

“This event not only demonstrates a level of interchange, but more importantly, it demonstrates the willingness of the vendors to work together to satisfy a critical need among the user community,” said Sanford Friedenthal, chair of the MIWG.

“I congratulate all the participants on achieving this significant milestone on the path to demonstrating complete XMI interoperability between tools supporting OMG modeling standards”, said Richard Mark Soley, Ph.D., OMG President and CEO. “Exchanging UML, OMG SysML and UPDM models with customers and suppliers helps realize the full benefits of capturing hardware and software designs and enterprise architectures using these widely-used precise modeling notations. I believe this demonstration will accelerate the adoption of model-driven engineering techniques in general, and OMG’s Model-Driven Architecture in particular, by guaranteeing the ability to combine best-of-breed modeling tools in both inter- and intra-enterprise tool chains.”

The MIWG was established in December 2008 to demonstrate and enhance the interoperability among UML-based modeling tools using XMI. The XML Metadata Interchange (XMI) format is the OMG standard for exchanging models. The group’s focus is on model interchange between UML, OMG SysML™, and Unified Profile for DoDAF and MODAF (UPDM) -capable tools. The MIWG comprises end users, tool vendors and experts in the UML and XMI standards. The US National Institute of Standards and Technology (NIST) is providing an XMI validation tool that forms a key part of this process. Model Driven Solutions (MDS) and Adaptive have been providing additional technical expertise and configuration management support of the modeling artifacts.

The MIWG uses an incremental testing approach to demonstrate interchange with increasing levels of interchange. To date, the MIWG has completed six test cases encompassing class models, activity models, composite structure models, and simple profiles. Issues resulting from the testing are identified and addressed. The testing results to date demonstrate a significant level of interchange capability across multiple tools. The plan is to complete interchange testing of the majority of UML functionality by the end of March 2010, and then to proceed with SysML interchange testing. Following the completion of the base level of SysML testing, the group will proceed with UPDM interchange testing, which leverages both UML and SysML. The US Department of Defense, the UK Ministry of Defence, and NATO have all emphasized the criticality of this capability, and are closely monitoring the results from this effort. Information on the MIWG, the test cases, testing approach, and plans are available on the group’s Wiki page at http://www.omgwiki.org/model-interchange.

Participants

The organizations currently participating are:

• Artisan (participating tool)
• IBM (participating tool)
• SOFTEAM (participating tool)
• No Magic (participating tool)
• Sparx Systems (participating tool)
• Adaptive (Test case construction, validation and support)
• MDS (Test case support and version control)
• NIST (Independent test case validation)
• Lockheed Martin (Chair)

How to get involved

The MIWG will continue to conduct interoperability test coverage for UML, SysML and UPDM. Any organization wishing to participate in the MIWG is encouraged to join OMG. For more information on OMG membership, please contact Ken Berk, vice president, business development at .(JavaScript must be enabled to view this email address) or +1-781-444-0404.

Comments

Comment on this article

Page 4 of 4 pages ‹ First  < 2 3 4