Scope
For objects as well as for activities, complexity is a matter of structure, and such descriptions must be rooted at requirements level if they are to be dealt with properly. On the other side, since complexity may also come from classifications, rules, or connections, patterns should provide some unifying perspective.
Abstract Data Types
As it happens, a framework is already available from design patterns and can be easily applied to requirements.From that perspective, two criteria must be taken into account:
- The first criterion deals with structure specialization, depending on the distinction between composite (nodes) and atomic (leaves) elements.
- The second distinction is about targets: descriptive structures handle instances of objects or activities, prescriptive ones deal with the possibilities to create such instances.
Compositions can then be refined depending on cardinalities and associated information:
- Trees are used for hierarchical structures, each elements with a single owner; graphs are used to describe neighboring connections.
- Augmented structures are introduced when information is associated to connections; decorated structures are necessary when business contents and composite structures are managed independently.
Composite Objects
Composite objects can be described at three levels: physical, symbolic, or generic.
- Physical descriptions deal with actual components independently of associated data
- Symbolic descriptions deal with the management of individual vehicles.
- Generic descriptions deal with the features and rules shared by subsets of vehicles.
Composite Activities
Composite activities should be described with the same patterns applied to:
- Process execution states.
- Scheduled maintenance operations and log of completed ones (class diagram with references to activities).
- Protocols of maintenance activities: sequencing rules of operations (activity diagram with references to maintenance handbook).
Composition & Abstraction
Whereas variants in objects or activities can be described either by specialization or by alternative structures, each representation brings its own semantics. Some consolidation of those semantics should therefore provide a better understanding of modeling options. As proposed by the UML# Manifesto, that could be achieved by introducing a distinction between identities and features both for composition and specialization:
- Strong construct (aka composition) or specialization applies to intrinsic features of identified objects or activities.
- Weak construct (aka aggregation) or specialization applies to contingent features not necessary bound to the identity of objects or activities.
Composition & Association
From an architectural perspective, one must set apart structural integrity constraints from functional ones. The former deal with objects (persistent or transient) and can be managed at architecture level, independently of the specificities of business domains and processes, the latter necessitate access to object features and semantics.
UML uses diamonds to describe structural integrity constraints. The additional notation (#) can be used to indicate bound identities between objects belonging to different domains.
To take documents as an example:
- A document is (partially) identified by its author (from another domain).
- A document contains a summary (local) and parts (exclusive but mutable ownership)
- Parts contains other parts (exclusive but mutable ownership), paragraphs (exclusive and frozen ownership), and illustrations (from another domain).
Connectors can also be stereotyped according set-based constraints:
- Collections (*): for structural or functional sets.
- Exclusive connectors: for non overlapping partitions.
- Inclusions: for subsets and subtypes.
A special mention is to be made for shared (aka multiple, aka cross) composition which describe objects whose identity is defined by two or more references, in other words components that belongs to (i.e are owned by) more than a single root. In UML it is represented by association class. It would be interesting to see how that constructs could be generalized to other types of connectors: communication channels, data and control flows, and state transitions.
