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.
