Explicit, Implicit, and Inferred Relationships
LouV 270001TJS7 Visits (8735)
You can look at the world around us as categorized into three kinds of relationships – Explicit, Implicit, and Inferred.
Explicit Relationship -- Like a Marriage
An explicit relationship is one that carries data on the relationship itself – the ‘join’ relationship. So for example, a marriage between two people carries information about the anniversary date, and the names of the people involved. In the modeling world, for those of you who are familiar with a CRUD matrix – the matrix you use to understand if a business process Creates, Reads, Updates, or Deletes a table in a database – it has a ‘join’ definition that carries this data. In System Architect, we have always referred to these kinds of matrices as ‘text in cell’ matricies, because you can put information (not only text, but lists of other definitions, so it is a bit of a misnomer) into the cell. In DoDAF 1.5 ABM, there are ‘triplets’ formed on both the operational and systems side – you specify the Role(s) that perform an Activity at an Operational Node in the OpNodeActivity ‘join’ definition (and respective matrix), and similarly on the systems side, you specify the System (Entities) that perform(s) a System Function on a System Node in the SysNodeFunction ‘join’ definition (and respective matrix).
Implicit Relationship -- Like Twitter
An implicit relationship is a simple list. Sometimes you don’t care to capture information in the relationship – it goes beyond the scope of what you need to model in an architecture and makes building and maintaining the architecture tedious. A real-world example of an implicit relationship is Twitter. If you have a Twitter account, you know that you have a list of followers (and a list of people that you are following). That’s the only thing being captured about the relationship – the simple fact that you have a list of followers. In System Architect ‘parlance’ this is a property that is a ListOf other definitions, or a property that is a OneOf other definitions.
Inferred Relationship -- Like 'Six Degrees of Separation'
An inferred is the old six degrees of separation ‘hopping’ – if x is related to y is related to z, then x is related to z (through y). Clint Eastwood is related to John Wayne because they both played in movies directed by Don Siegel. In System Architect, you use the reporting engine to run SQL-like queries to get at this information and generate reports to publish it. Over the last six or so years, you’ve had the Explorer diagram to visually show the ‘cause-effect’ relationships – so you can run an ‘Explorer relationship report’ to visually show a direct relationship between, say, a Server and Capabilities it provides, if you run a report that goes from Capability to Activity to Application to Server. You can skip (or hop) the intermediary definitions if you want to visualize the ‘end game’.
In IBM Rational System Architect, you can automatically visualize all of these relationships on any diagram type. Functionality was added in SA 11.4.1, to the saprops/usrprops metamodel language, that enables you to specify that a relationship is Explicit or Implicit – instructing it to draw itself between two symbols on a diagram if the underlying definitions are related in such a fashion. You can also run ‘Explorer relationship reports’ on any diagram type (not just Explorer diagrams) to visualize ‘inferred’ relationships between definitions.
I can see the question forming in your mind – what relationships then, should be explicit, and what relationships should be implicit in an architecture? The subject of another blog.