Synopsis
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.
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).
Subsets
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).
The same pattern can also be applied to execution units whose variants are exclusive and identified by the same argument.
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.
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.
Extension
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.
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.
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.
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.
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.
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.
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.
Power-types
This pattern is used when all subsets can be described by the same features but with some of them valued uniformly.
Applied to activities, it will represent alternative strategies, e.g computation rules.
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.
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.
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.
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#) .
