Scope
Containers are used to manage objects or activities independently of their features or behaviors.
Physical vs Symbolic Containers
Physical containers are introduced to address actual objects and control processes execution. Symbolic containers are used to regroup descriptions whose semantics are managed under a single authority. Collection are introduced to manage sets of elements, actual or symbolic. As such they can represent physical locations, process resources, organizational domains, or collections.
- Spatial locations are actual containers grouping physical objects, active or passive. That include the physical storage of symbolic objects.
- Run-time locations are actual containers within which processes can be executed, and therefore controlled, under a single clock.
- Business domains are symbolic containers describing the semantics and consistency of persistency units.
- Applications domains are symbolic containers describing the semantics and consistency of transient units.
- Organizations are symbolic containers regrouping business and application domains.
Containers vs Collections
Contrary to symbolic containers which are defined at organizational level and deal with descriptions, collections are symbolic objects introduced to manage multiple instances uniformly,
Instances can be managed anonymously or individually. For anonymous elements, the containers are used to manage tallies.
For elements identified individually, containers keep track of contents and can perform basic operations like sorting or computations. Weak or strong structure operators are used depending on the ownership held by containers.
Applied to activities, symbolic containers may be used to describe the control and synchronization of simultaneous activities: an aggregate structure will be used if the control can be transferred, otherwise a composite structure is needed.
Collection containers are also used to represent subsets of items, persistent or transient, associated to partitions.
Combined Representations
As illustrated by programming languages constructs, there is much to be gained using predefined collections for both objects and behaviors. Moreover, since semantics are non ambiguous and consistent all along the development path, from requirements to design, there is a strong incentive to unify descriptions and bring benefits upward into requirements.
Regarding objects, explicit representation of containers will enable:
- Distinction between containment (e.g village > hearths) and links (e.g village-village)
- Distinct representations for (1) containment connectors between actual objects (requirements) and (2) standard relationships between symbolic representations (analysis).
- Mapping of actual links to symbolic relationships (e.g neighbor).
Iterative activities can then be associated to symbolic representations of actual containers.
