I’m trying to figure out how to model a situation with following properties:
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:
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
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:
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:
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)
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.