How do you represent different versions of the same entity type (class) in the same UML class diagram?

Question

I’m trying to figure out how to model a situation with following properties:

• there is a set of entity types Ei...Ej and a set of relationship types between those entity types Ri...Rj in the domain;
• one can distinguish at least two different versions of those entity and relationship types that are significant to different parts of the system at the same time.

In the simplest case, those different versions might be “real time data” version and “last approved snapshot” version. In this case, being significant to different parts of the system might translate into following:

• there are less privileged actors and use cases, that can only work with “last approved snapshot” version;
• at the same time there are more privileged actors with the same or different set of use cases, that can work with “real time data ” version;
• there are entity types Ex...Ey that either form relationships with entities ei...ej from “last approved snapshot” version or whose constraints reference values of attributes of entities ei...ej from “last approved snapshot” version;
• at the same time there are different entity types Ea...Eb that either form relationships with entities ei...ej from “real time data” version or whose constraints reference values of attributes of entities ei...ej from “real time data” version.

If I want to show all entity types Ei...Ej, Ex...Ey and Ea...Eb from aforementioned example along with their constraints and relationships between them on the same diagram, how would I do that?

I was thinking about using two different classes for the same entity type: one class would represent “last approved snapshot” version of that entity type and another class would represent “real time data ” version of that type.

But I don’t like this approach very much as

• it seems redundant;
• I’m not actually sure what kind of relationship there is between two classes representing two different versions of the same entity type a how to represent that relationship in diagrams (maybe «derive» stereotype from standard profile would be appropriate here, but I'm not sure).

---

EDIT

Unfortunately, I can’t use examples from my work, so I’ve come up with this completely fictional one, but one that is also partially modeled after the problem I was trying to solve recently. I’ll be using popular “WorksInUsing” association to pay proper respects. This will make the question more concrete.

Also, to be clear, I’m trying to create conceptual model and not so much OOP/relational design/implementation model.

Let’s assume an entity type Employee.

Let’s assume an actor called “SkillAdministrator” managing following entity and relationship types:

• entity type Skill
• entity type Department
• relationship type KnownSkill between entity types Employee and Skill
• relationship type WorkInDepatment between entity types Employee and Department

Let’s assume, that changes in all those aforementioned entity and relationship types happen rarely but when they do they happen in very large batches and our skill administrator needs quite a time to process each such change.

After he’s finished processing the change, he runs PublishChange use case which creates a snapshot of entity and relationship types Skill and KnownSkill and makes that snapshot available to other users of the system.

Let’s now assume an actor called Manager managing following entity and relationship types:

• entity type Project
• relationship type WorksInUsing between entity types Employee, Skill and Project.

Only those Skills that existed at the last run of PublishChange use case can play role in WorksInUsing association. Also the pairs KnownSkill are precondition to triplets WorksInUsing, but again only those KnownSkill pairs, that existed at the last run of PublishChange use case.

At the same time Manager is managing WorksInUsing associations, SkillAdministrator can start working on processing the next big change in entity and relationship types that he manages. Manager doesn't see those changes, not until PublishChange use case is run again.

(Depending on the domain, there are multitude of different ways to handle deletion of particular skill or knownskill association by system administrator and then applying those changes - in the simplest case, both types could be assumed as permament, so new instances can be added but existing instances cannot be deleted, for examples laws work this way)

Answer 1

Actually there's not too much choice. Either you have to distinguish between inheritance or via a flag

There are pros and cons for both solutions depending on the domain/context. In this case I would just tend to use the flag variant. Simply because it represents sort of a state that can change (see also here as suggested by @Christophe). Choosing inheritance would make it complicated to make a non-approved snapshot an approved one (you would need to create a new instance and copy the contents).

In any case you need some constraint that will describe how access is limited so that certain actors can deal with the one or other variant. Just apply Occam's razor and don't try to find overly complicated models where simple ones will do as well. For a hobby purpose or to puzzle/stun others that's nice. But in practice?

Answer 2

I was thinking about using two different classes for the same entity type

that can mean classes appear and disappear following the entity approval history !

Supposing there is not yet an approved version, so just a real time version evolving over time, when that version is approved there still only one version being both the last approved and the real time version, may be you can use the same class being now approved. Then a very first change must be done, so the last approved version still exists and is cloned to create the class for the real time version. When that real time version become approved the already existing last approved class must be deleted. Etc

An actor (in the non UML use case sense) have to access the right class to try to interact with.

I am not you sure you want that working at the meta model level.

---

A second way is to have a class always managing the last approved version and an other class managing the real time version, at a given time there is zero or one instance of each class, but at least one of them when an entity exists.

Supposing there is not yet an approved version so no instance of the last approved version class, so just an instance of the real time version class evolving over time. When that version is approved an instance of the approved version class must be created from the real time class instance then that least must be deleted. Then a very first change must be done, so the instance of the last approved version still exists and is cloned to create an instance of the class for the real time version. When that real time version become approved the already existing instance of the last approved class must be updated or deleted and an other instance created, and the instance of the real time class deleted. Etc

An actor have to access the right instance of class to try to interact with.

---

A third way is not to use different classes but different instances of the same class. During entity approval history the instances are created/deleted in the same way classes was in the first way. But the level is not the meta model.

Like in the previous way an actor have to access the right instance of the class to try to interact with.

---

A fourth way is to use the same instance for all versions of an entity existing at a time, the instance being able to react in the right way depending the view of it is used by an actor, also checking the actor is authorized or not. Each instance is created one time for a given entity, whatever the version(s) and the approval history.

Because there is only one instance the actor does not have to choose between several instances/classes. If you have association between entities they are all the time the same and do not have to be created/deleted depending on the versions of the entities.