Page 1 of 3 pages  1 2 3 > 

What Would a TRAK View Look Like in a Graph Database? Part 1

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.

Display full size image.

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

Comment on this article

Related Articles

• Conformance Assessment vs ISO/IEC 42010:2011

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% )
• Definitions - What Exactly is a Risk Part 2? (13% )
• Just When You Thought It Was Safe - EntiTy Returns (13% )

External Links

• TRAK00013 : TRAK. Architecture Description. Conformance Assessment. ISO/IEC/IEEE 42010:2011
• Neo4J graph database
• Neo4J - What is a Graph Database?

Risk and Threats - The Common Ground Between Security and Safety?

This is something that has been bumbling around for some considerable time - safety and security. By that I whether there is something useful that an enterprise architecture view can be used for in the system safety and security disciplines.

On the face of it there is quite a bit of overlap. Both are ultimately concerned with risk inherent in a solution design which arises from threats (security) or hazards (safety). Both involve management with the aim to reduce the risk, threat or accident (safety) to an acceptable or tolerable target. I suspect also that security management also uses categories to classify acceptable severity or probability in much the same way that the various system safety management standards in defence do (MIL STD 882D, DEF STAN 00-56). Both also involve mitigation of risk by design - through structure, behaviour, or adherence to a normative process of some sort.

There are bound to be some differences, not the least of which is terminology. In the security area we seem to have constructs like:

• Threat poses Risk
• Threat exploits Vulnerability
• design aka TRAK:Resource (System, Software, Organisation, Job or Role) exposed to Risk (and subsequently that Risk is mitigated by the (improved) Resource or Function (of that Resource)

In the safety area we seem to have constructs like:

• Failure may present Hazard
• Hazard can cause Accident
• Accident poses Risk
• Resource exhibits Failure

and attributes such as probability, impact, severity.

Anyway it seems sensible to open up the debate so I’ve posted some thoughts in the forums within the TRAK Viewpoints project site on Sourceforge. Something is definitely needed and my hunch is that there is so much overlap that it would be possible to create a Viewpoint that addresses the risk within a solution design. This may of course end up being two viewpoints depending on the concerns and therefore concepts (metamodel stereotypes) and relationships involved. What is needed is more debate and input from those involved with system safety and system security - hence the post. As ever with TRAK the objective is economy so that we have something that is just or barely adequate to describe the concerns and concepts involved and no more.

Comments

Comment on this article

Related Articles

• Keep Clear Separation Between the Concerns that Each Architecture View Addresses

Sharing tags:

• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (41% )
• Definitions - What Exactly is a Risk? (29% )
• Just When You Thought It Was Safe - EntiTy Returns (24% )
• Definitions - What Exactly is a Risk Part 2? (24% )
• What Would a TRAK View Look Like in a Graph Database? Part 1 (18% )

Forums

• See discussion thread in forums

External Links

• DEF STAN 00-56/4 Part 1 / Part 2 Safety Management Requirements For Defence Systems.  [registration needed to access]
• MIL STD 882D. Department Of Defense Standard Practice For System Safety. February 2000
• Cabinet Office. Security Policy Framework. V7 October 2011.
• Security Ontology. Stefan Fenz.
• Secure Business Austria. Security Ontology.
• HIPAA Security Series. 6 Basics of Risk Analysis and Risk Management.
• Safety & Functional Safety. ABB Brochure 1SFC001008B0201.

ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture Description Released

Just received news from Rich Hilliard via the IEEE 1471 Users List (to become the “ISO/IEC/IEEE 42010 Users List):

Today I was notified that IEEE P42010 was approved as a revised standard by the IEEE-SA Standards Board on 31 October 2011.

This standard replaces IEEE 1471:2000 and is identical to the ISO standard approved in July with 21 approvals and 0 disapprovals from member bodies.

The new standard, designated ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture description, is available from IEEE and ISO.

The IEEE 1471 website will become the ISO/IEC/IEEE 42010 website.

The old website will redirect to the new URL which is:

• https://www.iso-architecture.org/42010/

Looking at the website I noticed

Per IEEE rules: An approved IEEE standard will remain active for   ten years. If the Sponsor does not complete a revision process   within ten years, the standard will be transferred to inactive   status.

Curious to know whether this means a standard has to be revised or whether the requirement is simply to review - it might still be a perfectly good standard even if it hasn’t been revised since the decision might be on review that it’s good enough.

Having to say ISO/IEC/IEEE every time is a bit of a mouthfull and therefore inevitably will be shortened in everyday use. Is there an acceptable shortform(s) e.g. ISO 42010, IEC 42010 and IEEE 42010? It’s unlikely in speech that the full qualification will be used.

Comments

Comment on this article

Related Articles

• Conformance Assessment vs ISO/IEC 42010:2011

Sharing tags:

• What Would a TRAK View Look Like in a Graph Database? Part 1 (40% )
• Risk and Threats - The Common Ground Between Security and Safety? (40% )
• Definitions - What Exactly is a Risk? (20% )
• Definitions - What Exactly is a Risk Part 2? (20% )
• Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (20% )

External Links

Page 1 of 3 pages  1 2 3 >