Objects can be concrete or symbolic, systems are designed to process their symbolic reprsentations.
Business objects and activities are represented by symbolic objects, persistent or transient; those symbolic representations must be physically implemented and duly identified as persistency or execution units if they are to be processed.
Since persistent representations must be consistently and continuously mapped to their actual counterparts across activities, some mapping mechanism has to be introduced. A naive solution would use some part as a proxy to represent the whole. Yet, whereas the mapping could be enforced, the representations could not be processed independently of their actual counterparts.
A somewhat better solution could be to use look-alikes built on purpose, and to select a supposedly unique feature to identify both object and representation.
If unicity could not be guaranteed for actual features, one could design a symbolic one and attribute it to both actual objects and representations.
Transient Symbolic Representations
The problem for transient representations is somewhat different since they are only to be matched while activities are executed.
On the other hand, instructions as how to create, process, or delete objects must be kept at hand, and that is the rationale behind types and models.
Models are needed to describe how contexts should be consistently mapped into symbolic representations, more precisely they will define:
- Primary objects with individual persistent identity, to be mapped directly to their representation.
- Dependent objects, whose mapping is done through primary ones.
- Subsets of objects associated with the same features.
- Primary activities with individual identity, whose context has to be consistently represented until completion.
- Dependent activities, whose context is managed by primary ones.
- Subsets of activities associated with the same features.
- Actual and symbolic connectors, persistent and transient.