When looking at any complex relational system (especially in software, where our diagrams are limited by object scope), how do we see all the connections? How do we see and understand all objects, cases, states and methods (actions) regardless of the entire mutually inclusive and exclusive scope?
The standard method for showing hierarchical relationships, both inclusive and exclusive, is to use multiple diagrams for modeling those relationships between domain objects and related phenomena. The problem with this is that using multiple diagrams to portray a top-level view can lead to confusion and redundancy. Often, it would be extremely helpful to be able to have a single macro view of the data/objects and all relationships, rather than relying on piecing together multiple micro diagrams to achieve the same effect. It requires a higher level of abstraction to view complex data/objects on a macro level, and unfortunately, as we abstract we also lose detail.
What if there was a way to reduce all relational hierarchy to a single diagram without a significant loss in detail?
I have always been fascinated with data/object visualization and reducing the complexity typically present in that field. I find that there are better ways to represent data/objects and the relationships between them. And so I set out to design a method for a single visualization format; the result is an application I call NuGenObjective OCIDML. That's a mouth-full, but I'll explain.
Introducing NuGenObjective OCIDML
OCIDML stands for Objective Case Interaction Diagram Markup Language. NuGenObjective OCIDML is a domain simulation method I created that drastically reduces the redundancy we commonly see in visualizing data/object relationships. This method provides for a single and simple view of all objects within our domain and their subsequent states, actions and interactions.
Take, for example, this diagram, which uses OCIDML to show the objects, cases, states and roles and their dependencies on each other for an entire system:
(clicking any of the images below will give you a larger, more detailed image)
Now examine this diagram, which uses OCIDML to show the (hypothetical) structure of three higher educational universities:
The structure of these organizations is not unique. For example, MPIM is a research institute and has no graduate program. So the part of the diagram corresponding to MPIM has no interactions dedicated to graduate students.
If we were to represent this same relational system with the usual 2D table (Excel or otherwise), we would draw a large 3×3 table with each cell being a 9×9 sub-table (including headlines). In this way we would have a 736-cell table and if every small cell were only 1.5 inches long and 0.5 inches wide (to make the inner text readable), we would have a 41×14 inch wide table, which would only display 54 of the 736 cells. The total space required showing these relationships in the traditional 2D method would exceed the usable space more than 14 times.
Using the OCIDML method we are able to display all necessary objects (with their states, relationships and actions) represented in a single visualization, giving us a macro view for each object, its state’s, actions and interactions with other objects. It allows us the advantage of seeing all dimensions, displayed in a single visual vector, whereby the relationships and their multiple and singular entities are visualized.
Below is an example of building a diagram in the application. While relative to the actual tool, it should give you an idea of how it comes together. A great feature of the tool is the ability to double click on any interaction point. This will then display the specific object, role, state and action.
This is the interaction creation/definition dialog where we define our case for a specific object, role, action and state.
OCIDML for Software Development
When we design software we limit our cases by scope. But OCIDML makes it possible to diagram the entire network of relationships, paths, states and components of an object. This can be extremely useful in the software architecture process, allowing the architect to have a strong sense of the "whole" and all the inter-relational dependencies that need to be accounted for. In turn, software engineers will receive a more solid blueprint, resulting in better software.
Coming Up
In the next post in the series I'll dig into the mathematical theory NuGenObjective OCIDML was built upon and share some of the markup I used to create the diagrams. The application code is open source and I'll be getting it ready to share with you for the next post.
In the third and final post in the series I'll focus on specific use cases and talk about how you can use OCIDML in your software projects. I'm happy to answer any of your questions about this method – feel free to leave questions in the comments below.
