The Residual World::Tag = 'Compliance'
Entries that have been tagged with 'Compliance'.-
What Would a TRAK View Look Like in a Graph Database? Part 1
by Nic Plum on Monday 31 August, 2015 - 15:38 GMT
Posted in Architecture Framework • TRAK • Standards • Tools
Tags: compliance • conformance • graph • iso42010 • standard • trak • triple • tuple
The trouble with using a lot of the enterprise architecture tools is that they were originally developed for software development. This means that they tend to focus on / provide functionality for the expression of objects rather than relationships and they typically use software notation to describe the relations, for example the UML. If you are primarily interested in relationships it is then quite hard to exploit and query the relationships. There is also the inevitable problem with the readability of the result particularly for the non-technical and non-software audience who haven’t grown up with, say, UML Class diagrams.
TRAK is defined in a solution-agnostic way and specifies that all the relationships must be 1) visible; 2) labelled so that the assertions / tuples can be read as simple sentences e.g.
- System. A is configured with B. Software, or
- Argument. D supports Claim. Y
This means that it is easer to read. It is still up to the implementer and the notation (an Architecture Description Language in ISO/IEC/IEEE 42010 terminology) how this appears when visualised. You might, for example, get the following.
This isn’t too bad to read thanks to the TRAK requirements to make everything explicit but if you want to follow relationships and display the results you typically have to dive under the hood create a query that has multiple table joins. Even then the result is a table which isn’t the best way of presenting a structure. If you wanted to recurse down a structure to display something and its parts you might not be able to do this without knowing how many levels you needed to traverse to retrieve the results.
It soon gets all too difficult which is a shame because having created the relationships the real power over a ‘flat’ diagram is the ability to query them to answer questions.
Is there another way? In a nutshell, yes. A TRAK view is defined as a set of assertions / tuples / triples. In mathematical terms these are ‘graphs’ and now you can get graph databases that store graphs rather than tables. It’s therefore a straightforward exercise to create a TRAK view in a graph database using the governing TRAK viewpoint (which constrains what tuples can be shown) and the TRAK metamodel as the ‘domain model’ for reference.
I’m in the process of evaluating the free community edition of the Neo4J graph database. The plan is to create a complete architecture description within Neo4J to show how it might look as a set of graphs. Neo4J is pretty straightforwards and the reference manual, online training and free e-books are valuable. I wanted to produce the equivalent of a TRAK architecture description that is already online so I’m porting the one that was used to support the formal conformance assessment of TRAK against ISO/IEC/IEEE 42010:2011. This particular TRAK architecture description makes a lot of use of the MVp-04 Assurance Viewpoint since it describes a structured set of claims (of compliance), arguments and evidence.
This has been achieved using the CSV import capability of Neo4J to import the elements and their properties. For example the import of the TRAK requirement elements was achieved using:
LOAD CSV WITH HEADERS FROM “file:///requirements.csv” AS row
CREATE (n:Requirement)
SET n = row,
n.`object ID` = toInt(row.`object ID`),
n.`AD exchange element owning ID` = row.`AD exchange element owning ID`,
n.`AD exchange element owning organisation`=row.`AD exchange element owning organisation`,
n.`reference URL` = row.`reference URL`,
n.`sequence ID`=toInt(row.`sequence ID`),
n.`requirement ID`=row.`requirement ID`,
n.`compliance level` = row.`compliance level`,
n.`requirement paragraph` = row.`requirement paragraph`,
n.`requirement scope` = row.`requirement scope`,
n.`requirement type` = row.`requirement type`,
n.`requirement priority` = row.`requirement priority`,
n.name = row.name,
n.description = row.description,
n.`requirement owning org` = row.`requirement owning org`,
n.`element author`= row.`element author`,
n.`created date` = row.`created date`,
n.`modified date` = row.`modified date`
SET n :Requirement:`Architecture Description Element`CREATE CONSTRAINT ON (reqt:Requirement) ASSERT reqt.`object ID` IS UNIQUE
All the different TRAK metamodel elements have been imported similarly and connected together, e.g.
LOAD CSV WITH HEADERS FROM “file:///claim_about_requirement.csv” AS row
MATCH (claim1:Claim {`object ID`: toInt(row.Start_Object_ID)})
MATCH (reqt1:Requirement {`object ID`: toInt(row.End_Object_ID)})
MERGE (claim1)-[r:`about`]->(reqt1)
ON CREATE SET r.`connector ID` = toInt(row.`connector ID`);CREATE CONSTRAINT ON (conn:`about`) ASSERT conn.`connector ID` IS UNIQUE
TRAK also has elements to represent Architecture View so its easy to relate the elements and the connectors to the view(s) that show them.
In Neo4J queries match patterns (think of these as paths through the underlying architecture description - the sets of tuples). Suppose for example I want to show the structure of the standard itself. Off the top of my head I don’t know how deep the structure is but this doesn’t matter since the Cypher query language allow me to recurse to the bottom.
The query to show the requirement structure is simply:
MATCH (a:Standard {name:'ISO/IEC/IEEE42010:2011 Systems and Software Engineering - Architecture Description'})
MATCH (a) -[r:`has part`*1..]->(b)
RETURN a,b, r
which simply tells Neo4J to start with the topmost node - a TRAK ‘Standard’ and then look for all the outgoing ‘has part’ relationships for as many levels as needed and then return the nodes and relationships. The result of this is shown below.
Finding orphan nodes with no relationships is as simple as:
MATCH (node)
WHERE NOT ((node)—())
RETURN node;
It’s not yet TRAK-compliant. I’ve still got to figure out how to get the cascading style sheet to display the TRAK metamodel element type (‘label’ in Neo4J) but it’s already a very useful tool to exploit the relationships made. This is with Neo4J out of the box as a bare database i.e. with no application built on top of it. It ought to be relatively straightforwards for a software engineer to extend this to implement the TRAK viewpoint definitions and visually query the database. Or I should add that it is if you’ve got a simple and explicit metamodel because it’s easy to square this with the graphs produced. If all you’ve got is a more indirect and complicated one enforced via a UML profile it’s a much harder task and you can’t then easily verify the result against the original views in the modelling tool.
Comments
Related Articles
Sharing tags:
- Risk and Threats - The Common Ground Between Security and Safety? (38% )
- Definitions - What Exactly is a Risk? (25% )
- Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (25% )
- Just When You Thought It Was Safe - EntiTy Returns (13% )
- Definitions - What Exactly is a Risk Part 2? (13% )
External Links
Conformance Assessment vs ISO/IEC 42010:2011
by Nic Plum on Thursday 22 September, 2011 - 12:59 GMT
Posted in Architecture Framework • TRAK • News • Standards
Tags: compliance • conformance • ieee • iso • iso42010 • standard • trak
It’s very hard when everyone seems to be claiming conformance with ISO/IEC 42010 to establish whether the claims are true. All too often we get ‘partly compliant with ’ which means what exactly? As a standard trying to get standardisation in the field of architecture description and trying to eliminate the variability and anarchy it isn’t much use to be partly compliant (any more than claiming to be partly pregnant). You either do or don’t conform. The hard work put in by those that try to conform to the standard is undermined by those that claim conformance but don’t actually conform.
I’m pleased to be able to say that TRAK has agreed to take part in a pilot against an official ‘conformance assessment instrument’ prototype that is being developed against ISO/IEC 42010:2011 which is soon to be jointly published by both the IEEE and ISO. The conformance instrument applies to Architecture Frameworks, Architecture Description Languages and Architecture Descriptions.
As ever I’m sure the assessment and feedback will benefit both sides in refining and sharpening up the documentation. These are early days and no doubt some ideas still need to be worked through, hence the pilot using the prototype conformance instrument.
I’m quietly confident with respect to TRAK itself (time will tell!) but more importantly it will be useful to have an independent assessment of any claim to conformity whereas the current situation allows any Tom, Dick or Harry to claim conformity with impunity and where no sanctions can be applied. I look forwards to this situation being changed.
Comments
Related Articles
Sharing tags:
- What Would a TRAK View Look Like in a Graph Database? Part 1 (71% )
- Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (29% )
- Definitions - What Exactly is a Risk? (29% )
- Definitions - What Exactly is a Risk Part 2? (14% )
- Just When You Thought It Was Safe - EntiTy Returns (14% )