Composition Patterns


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.

Composition Patterns

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.
Abstract Composite Data Types

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.
Physical, Symbolic, and Generic Composition

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).
Execution states, Vehicles maintenance, Sequencing rules.

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.
Consolidated Semantics for Composition and Inheritance


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.