Site

RW - Navigation

RW - Recent

Last 10 entries [comments]:

Forums

Last 10 posts [threads/views]:

Wiki

Last 10 pages updated:

There are 484 wiki pages in total.



RSS logoRSS Feed
 

The Residual World::Tag = 'Exchange'

Entries that have been tagged with 'Exchange'.-

Improving Consistency for Tools - ‘TRAK. Implementation. Architecture Description Elements’ Document

by Nic Plum on Monday 05 September, 2011 - 15:03 GMT

Posted in Architecture FrameworkTRAKTools

Tags: architecture descriptionconsistencydocumentexchangeimplementsolutionstandardtool

There is a constant need to reduce the scope for inconsistency in any architecture description. TRAK is no different. TRAK has been defined in a way that is free of implementation and using natural language wherever possible. One of the pitfalls of this is the possibility that names will be implemented inconsistently in tools. For example, the attribute ‘start date’ might be called ‘start date’, ‘start_date’, ‘startDate’, ‘Start Date’ and so on. The danger in this is that upon exchange the receiving tool might not recognise this if it is using, say, ‘startDate’.

I’ve therefore created a document titled ‘TRAK. Implementation. Architecture Description Elements’. To put it into context a couple of diagrams (produced using the OmniGraffle stencil for TRAK):

Context - the TRAK. Implementation. Architecture Description Elements documents is part of the set of documents that improves consistency of exchange of an AD

The TRAK. Implementation. Architecture Description Elements Document is Part of the set of Documents that Improves Consistency of Exchange of an Architecture Description

The TRAK. Implementation. Architecture Description Elements document responds to the logical TRAK Metamodel definition.

The TRAK. Implementation. Architecture Description Elements Document Responds to the Logical Definition of the TRAK Metamodel

The document is at http://sourceforge.net/projects/trak/files/Implement%20TRAK/

The purpose of this document is therefore to standardise the naming of the architecture description elements used in any implementation of TRAK, whether graphical or text-based.

In addition to naming this document also specifies the formats used for attributes such as text, language labels, geographic location and uniform resource identifier. It also identifies the allowed values where an enumerated list specified for an attribute.

None of this guarantees successful exchange - in a UML modelling tool there will be an extra wrapping applied through XMI which might be at a different version in the sending and receiving tool and in addition even if an element has the same name it might mean something completely different in each. This document is therefore one part of a set of normative measures needed to maximise the chances of successful interoperability between a pair of tools.

There are a couple of things still left to do, not the least of which is figure out how to specify privacy marking / security descriptor schemes. If anyone knows of any good standards-like sources for these please let me know.

Any constructive comments via the Sourceforge Tracker set up for implementation of TRAK at https://sourceforge.net/tracker/?group_id=393432&atid=2376222

Comments

Comment on this article

Related Articles

    {REL[6140][related1_blog]w7Ak3LlKREL}

    Sharing tags:

    Forums

    External Links

    How ISO/IEC 42010 Controls Architectural Description

    by Maestoso on Sunday 31 January, 2010 - 10:56 GMT

    Posted in Architecture FrameworkStandards

    Tags: architecture descriptionconceptconsistencyexchangeieee1471isoiso42010modelrulestandard

    ANSI/IEEE Std 1471 :: ISO/IEC 42010 - Recommended Practice for Architectural Description of Software-Intensive Systems

    ISO/IEC42010:2007 states that ‘most architects must work within an architecture framework’ where this is defined as ‘a predefined set of concerns, stakeholders, viewpoints and viewpoint correspondence rules; established to capture common practice for architecture descriptions within specific domains or user communities’.

    It controls architectural modelling at a high level by requiring architecture viewpoints that specify what concerns a particular view answers and what content a view must contain. It does not specify how the modelling is done or what presentation language must be used, for example UML, SysML, BPMN.

    image

    ISO/IEC 42010:2007 Conceptual Framework for Architecture Description

    UPDATE. The re-issue of the standard as ISO/IEC/IEEE 42010:2011 changes the underlying conceptual metamodel in the standard. This is shown on ISO/IEC/IEEE 42010 website.

    IEEE 1471 does not specify any particular one because it states that these are specific to the needs of a particular domain and there is not, as yet, any consensus on generic architecture frameworks. 

    In ISO 42010:2007 it specifies that an analysis be undertaken of the consistencies across the architectural views and any known inconsistencies be identified. Where does this consistency arise from, however, and what is the scope? It is perfectly possible for an architecture description comprising a set of models to be self-consistent. The problem is that another architect can choose to model using different object types and whilst again consistent the 2 architects will have produced 2 architecture descriptions that can’t easily be exchanged or re-used.


    IEEE 1471 is evolving and not only has the name changed to better reflect the application of architecture modelling - ‘Systems and Software Engineering - Architecture Description’ [draft 7, 25th January 2010]. It also has more on architecture frameworks and states that

    Correspondences and correspondence rules as specified in 5.7.2 and 5.7.3 may be used to express, record, enforce and analyze consistency between models, views and other AD elements.

    IEEE 1471 is definitely heading in the right direction and provides useful principles and rules. Simply making a reference to IEEE 1471, however, is not sufficient in order to control architectural modelling to the level needed to be able to maximise the likelihood of success for the exchange of architecture descriptions (or models). Correspondence rules are necessary but there are potential problems with sets of text-based rules (this affects any requirement collection). A metamodel defines that only the allowed element types and relationships that can be used in a model or architecture description. In essence it provides the architect with a mandated language of nouns (element types) and verbs (relationships) to describe the system of interest. It is also visual and a very concise form of specification. There will always be the need for additional rules to specify consistency between views for the system of interest but having a metamodel is essential to a consistent set of building blocks from which to construct the views.

    I’d argue strongly that having a declared metamodel is fundamental to defining an architecture framework and that without one you can’t hope to control consistency of modelling or meaning (semantics). excaim

    Even with a well-defined and controlled architecture framework there will be problems in exchanging architecture descriptions (and models) since modelling is a creative art providing many ways of modelling a particular thing and we have local or personal modelling styles. If we don’t share or have good access to a central set of definitions which includes elements and probably agreed boundaries (i.e. agreed understanding of the system breakdown structure) it is likely that elements will have different semantics.

    IEEE 1471 is a good start and an architecture framework with a metamodel helps, but there is a lot more to put in place to be able to successfully exchange and collaboratively develop architecture descriptions (and models).

    Comments

    Comment on this article

    Related Articles

      {REL[6165][related1_blog]w7Ak3LlKREL}

      Sharing tags:

      External Links

      What is TRAK?

      by Nic Plum on Monday 02 November, 2009 - 18:46 GMT

      Posted in Architecture FrameworkTRAK

      Tags: colaborationexchangehistorylondon undergroundmodafmodelportabilitystandardtrak

      TRAK - The Rail Architecture Framework - is an architecture framework (Editor - ‘no kidding’?) that was born within London Underground Ltd. based on MODAF and hence also DODAF.

      Like other architectural frameworks it provides a fixed grammar (objects and relationships) for representing the real world in architectural models - everything from the enterprise down to the technical products and interfaces. It also forms an interoperability or exchange standard to allow models to be exchanged with others.

      It has it’s beginnings in proprietary attempts to establish standards for system architecture. Prior to this there were single views of purely physical architecture. Architectural views of the physical, functional and geographic architectures of the underground were developed and the relationships between views established.

      A metamodel with a richer langauge for describing rail architecture was needed. There wasn’t any obvious architecture framework available within the rail industry that could describe systems other than computer or IT systems and after deliberation it was decided to adapt the MODAF metamodel for use within the rail domain.

      The driving needs have been:-

      • simplicity
      • pragmatism - good enough / fit for purpose is all that’s needed
      • recognition of hard and soft ‘systems’
      • supportable by tools

       

      The objectives in developing TRAK are:-

      • Standardising the content and presentation of rail architecture views. At present different companies, different projects present diagrams that mix ideas and presentation and which have no means of checking for consistency. Typically they are on paper, difficult to maintain and each diagram represents a fresh start in terms of the objects, descriptions and relationships shown.
      • Providing a standard for the exchange of architectural models of rail ‘systems’. There is no means to allow incorporation of the architecture represented on a diagram within another project or companies architecture.
      • Enabling portability of architectural models of rail architecture. Diagrams are paper or CAD files. One is portable but not easily integrated, the second is portable very restricted in those who can use it.
      • Collaboration. If models can be exchanged and re-used and standards define the component parts of the model then it becomes possible to collaborate.
      • Providing the means to show interactions and dependencies between enterprise, project, operational and solution component parts – i.e. a more complete systems engineering (holistic) view.

       

      The thing is .. having set out to create an architecture framework for the rail community we stripped out all defence-specific concepts, added things to better represent systems and organisations and have ended up with something that is generic. This shouldn’t have been a surprise - a system is a system and it doesn’t know whether it’s in rail or telecomms nor whether it is a hard or soft system.

      Comments

      Comment on this article

      Related Articles

          Sharing tags:

          External Links

          1.2.004 adl admin advice applescript application architecture architecture description architecture description language architecture framework artefact artisan studio award berlow blog boundary browser bug c3 capability capability configuration colaboration collaboration committee compare compliance concept concert conference configuration control conformance consistency content contrast css cv01 def stan defence definition demonstration denmark department for transport develop discovery dndaf document dod dodaf drawing enterprise enterprise architect ertms event evolve exchange exploit forum fun geneology gfdl gnu graph group handbook hazard head-model history humour ibm rhapsody iec ieee ieee1471 iet ietf implement implementation incose innovation institute integrated ea interoperability introduction ipad iso iso42010 isse keynote knowledge language linkedin lockheed martin london london underground m3 mac management mdg meaning meeting metamodel mil std modaf model modelling style naf nato natural language needline news nist no magic magicdraw noun omg omnigraffle ontology open source opensource operational organisation oxfordshire perspective plan platform playlist portability presentation procurement profile project public publication publish purpose rail relationship release repository research resource rfc4677 risk role rssb rule safety sea search security sentence service singapore site softeam modelio software solution song sos sourceforge sparx systems sparx systems enterprise architect specification spreadsheet stakeholder concern standard steering group stencil stereotype store strategy structure support sysml system system authority system of systems systems engineering team template test threat
           

          All articles/posts © of the respective authors

          Site design and architecture © 2010 - 2011 Eclectica Systems Ltd.