Specialization Patterns


Specialization patterns deal with the representation of variants and apply both to objects and activities. At requirements level (business objects and processes) variants are described by partitions, at analysis level (symbolic representations) variants are described by sub-types. Specialization patterns provide an architecture-driven rationale  mapping context variants into system ones, and so doing a principled traceability between requirements and analysis. That may be especially effective if and when power-types, selectors and extension points are to be traced through model layers.

Specialization Patterns (WALASSE TING)
Specialization Patterns (WALASSE TING)

Since patterns are meant to characterize problems with regard to solutions, the objective of specialization patterns is to provide handrails from  partitions (for the description of variants) to sub-types (that will support inheritance). For that purpose patterns are to be organized according two criteria: identification (for instanciation) and features (for behaviors):

  • Same features, subsets on values: power-type (a).
  • Specific features: abstract base type, concrete sub-types (b).
  • Additional features: concrete base type, unique sub-type (c).
  • Features only (aka aspects): types are abstract as they cannot be instanciated independently. They can be combined by inheritance (d1) or composition or aggregation (d2).
Basic Specialization Patterns


This pattern can be applied to subsets of objects with variant features yet identified by single mechanisms. Each subset can therefore be represented by a sub-type whose identity is supported by the base type. As a corollary, subsets are necessary exclusive; otherwise the number of instances would be different depending upon the level of abstraction (see external consistency).

Symbolic representation of exclusive subsets sharing a single identification mechanism.

The same pattern can also be applied to execution units whose variants are exclusive and identified by the same argument.

Symbolic representation of exclusive activity variants uniformly identified.

Type hierarchies should not be confused with functional decomposition: the subtypes are not part of the base type but, on the contrary, operations of the base type, first of all the identification mechanism, are included into the subtypes. More generally, specialization of objects or activities can be described at type level (white-box) or by detailing alternative composition.

Function vs Structure: specialization is not to be confused with its dual counterpart, ie alternate composition.

It must be noted that base types are necessarily abstract: since they represent the elements of exclusive subsets, they cannot be instantiated as such lest it contradict the substitution principle.


This pattern is a special case of subsets, with a single subset of objects with additional features. It may be useful when subsets are overlapping.

Symbolic representation of independently defined object subsets with variants sharing a single identification mechanism.

Contrary to exclusive subsets, base types of independently defined subsets are necessarily concrete since variants are meant to be extensions to individuals already identified. The same principle can be used with activities.

Symbolic representation of independently defined activity subsets sharing a single identification mechanism.

Yet, independently defined subsets may also signal a stopgap modeling solution between on one hand  subsets of a properly identified set of objects and, on the other hand, the mix and specialization of features defined independently of the type of objects supporting them. For instance, if headquarters are said to combine depot and garrison (a), those two cannot be defined as exclusive subtypes of fort (b); but opting for non exclusive subtypes (c) would contradict the substitution principle by enabling a different number of forts depending on abstraction level.

(a) & (b) are valid separately but not consistent with each other; (c) contradict the substitution principle.

Facets & Aspects

This pattern can be applied to sets of features (aka facets or interfaces) independently of identification mechanisms. That allows for specialization with multiple inheritance using standard qualifiers for conjunction and disjunction.

If identities are left aside, facets specialization can safely include multiple inheritance.

Whereas facets inheritance may find their equivalent with type hierarchies, semantics go opposite: roots inherits from leafs. And that difference points to main rationale for their use: the need to describe variants before a complete and final description of symbolic representations is available. That point is especially clear when the same patterns are applied to activities when initially described as functional aspects, aka use cases.

Functional aspects can be understood as use cases combined with UML dependencies <include> (a) and <extend> (b) & (c).

As a side benefit, use cases organization can be described on the same basis as other artifacts instead of UML’s specific ones: <extend> , for aspects included with qualifications, and <include> for other. Moreover, those patterns enable to describe integrity constraints on use cases organization without introducing additional operators. Last but not least, variants for roles (actors in UML parlance) and use cases can be described (and consolidated) using the same formalism.

Agents  and Roles

It must be reminded that roles are not agents and therefore have no persistent identities of their own. As a corollary, specialization applies to facets and consistency constraints  are to be enforced only when roles are played by identified objects.

The problem can be illustrated by bank customers: given that all customers have to be identified and authorized, it is tempting to define sub-types for private and corporate customers. Unfortunately that description of actors cannot be mapped to business objects because both private and corporate users are persons while corporate customers are organizations.

Nobody knows upfront if a user is bank customer

That misconception appears clearly when one consider use case execution: when a user connects his status is unknown and the system can only create a nondescript instance. He has to give some id before being associated with a private customer or an employee from a corporate one. Then, but only then, facets can be combined in order to define access rights.

Roles are functional placeholders and can be described and combined disregarding individuals standing behind.


This pattern is used when all subsets can be described by the same features but with some of them valued uniformly.

Power-types are used when variants are not about features, only about values.

Applied to activities, it will represent alternative strategies, e.g computation rules.

Power-types can be used to describe alternative strategies.

It’s worth to note that connections between root descriptions and variants are not binding: objects are not bound to partitions neither are activities to called functions.

Instantiated Power-types

This pattern is used for overlapping subsets with variant features. It combine subsets and power-types with parts played by objects being represented as such and therefore identified independently.

Repairs are identified by vehicle and time, with specific data depending on vehicle category and operation.

Applied to activities, it will represent alternative strategies, yet, contrary to simple power-types, computations cannot be performed instantly by calling the proper function. Instead, some collaboration is required between the primary activity (process) and the power-type, with transient objects (threads) needed to support it.

Computations are identified by operation and invoice, with specific data depending on vehicle category and operation.

Selectors and Extension Points

Selectors and extension points are where variants are decided, respectively for objects and activities. It must be reminded that they can only be applied to partition actual instances; as a corollary they cannot be used to instantiate them.

Citizens cannot be registered as such without prior existence as specialized instances.

Specialization Revisited

Whereas variants in objects or activities can be described either by specialization or by alternative structures, each representation brings its own semantics. That difficulty is compounded by the different semantics of inheritance when it comes to implementations and programming languages. Both ambiguities may be overcome by unifying the semantics of 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.

Those consolidated semantics can be easily supported by UML (cf UML#) .

Unified semantics for composition and specialization

Leave a Reply