This tutorial is about a strange corner of UML - and of EA - which you may have noticed, but perhaps not used.
But it's one which has a surprising power to make your models easier to understand and to manage, AND which can deliver new insights to your stakeholders.
Instance Classifier
The Instance Classifier relationship has a special status in EA, but it's special in a way we can use to our advantage, without necessarily knowing what it means in deep UML-speak (which is beyond both the scope of this article, and the authors knowledge).
If you come across the idea at all, it will be where you have drag/dropped a Class onto a diagram, then, when EA asks you do you want a 'link' (i.e. the Class itself) or an 'Instance', you choose 'Instance'.
EA will then associate the new instance with the Class it came from. And this is where the strangeness begins.
For a start, the relationship between the new instance (object) and it's Class is not implemented as a Connector - that is, as a line on a diagram. It's a special relationship, which is hard-coded into the EA data model. More important, in UML and in EA, any Element can have another element as its 'Classifier'.
It seems likely that was originally intended just to allow an instance of a Class (and Object) to be connected to its Class. Very sensible. But we can also use this 'special' relationship for other purposes. But first let's look at how this special relationship gets handled by EA.
The diagram above shows two classes, and two objects. But the Object Elements don't have any relationship to the classes. These were created as new Objects directly, not by dragging/dropping the Class and selecting 'instance'. They are just disembodied instances of some un-specified class, and so not very meaningful.
In the diagram above, we've create Instance#1 as an instance of Class3: you can see that by the name of the Class appearing after the name of the instance, in proper UML style. Instance#1 : Class3
So Instance#1 isn't just some random instance: it's an instance of Class3.
But notice that there is still no connector shown on the diagram: it's the ":Class3" which tells us there is an 'Instance Classifier' relationship between the two.
But there's more..
If this was the only use for the idea of Instance Classifiers, then they wouldn't be worth all this trouble.
But they unlock some really useful features in EA. For example, in the diagrams above, when the instances are connected up to their classes with Instance Classifier, then their names get modified: they get a colon (:) followed by their Class name.
We can use this for other purposes.
Below are two BPMN Process Diagrams, which use some <<Lane>>Activity Partitions, otherwise known as Swimlanes.
EA makes the Activities and decisions into children of the swimlanes, which keeps things tidy, but creates another problem.
Should we use the SAME swimlanes in the two diagrams? What about the 3rd and 4th diagrams? These swimlanes are going to get unmanageable if we have even a moderate-sized process model.
But the swimlanes are just proxies for the business role which they represent. It's how the role appears in diagrams.
The solution is to create and element which can be the single place where a role is defined. We've chosen to create a <<Business Role>> Actor element, which have the master definition of the role, and made them the Instance Classifiers of the lanes:
Again, there's no connector shown, but we can see that it's worked OK, as the name of the Lane also contains the Actor name, and it's this behavior which we want.
Now, whenever we create a new Process diagram, we can create a new Lane (element), and so long as we remember to connect it to the Actor (on the diagram above), we'll show the Actor name.
We have the Knowledge
This is a small help in managing your models, and every little helps, but we can use this to squeeze more insights out of our models.
When I'm teaching Process Modelling (with BPMN and EA, of course) a common requirement is for modelers to give their customers a 'role based view' of the processes. That is, a view of what's happening which does 't just focus on the processes, but on the people/roles which DO the process.
The problem with this is that the same role may appear in lots of processes, so traditional - diagram-based- techniques just can't deliver this. You'd have to read all the process diagrams, looking for the role name. Not practical.
But if you use the Instance Classifier as described above, then we already have all the knowledge to deliver this role-based view. Each Activity has a parent which is the Swimlane, and the swimlane has an Instance Classifier which is the role. All we have to do is follow the links backwards, from Role via IC to swimlane, and from swimlane to Activity children.
Showing it
If you print your documents using eaDocX, then we can use all these connections to show the role-based view.
eaDocX doesn't care that some of the links are parent/child, Instance Classifier or normal Connectors: it can navigate them all in the same way.
So we can show which Actors 'own' which activity, even though the Activities are Children of the Lane, and the Lane has an Instance Classifier of the Actor. So we're using both the 'Parent/Child' relationship, as well as the Instance Classfier one, just like we would any other Connector.
So our eaDocX documents can now show which Activities are owned by which actors, by tracing back through the Instance Classifier to the Lane, then down the the children of the lane - the Activities:
Using this feature may raise some new questions for our stakeholders. For example, does it make sense for this Actor/Role to be doing all these activities? Have we missed something, or given an Activity to the wrong part of the organisation? Now you're delivering real inight to the business, an all by doing the modelling in EA in a way which is easier for you to manage!
So the combination of a slightly clever modelling style - using Instance Classifier - and eaDocX, lets you both manage your model better AND get new insights into that model.
