Preamble
As primitive categories for the nature of existence of beings, Aristotle’s ontology put in front substance and quality. As it happens, that distinction appears to coincide with the two basic approaches to software design.
Objective
As far as systems engineering is concerned, models are symbolic representations built along two perspectives:
- The level of granularity to be considered, from elements and features to systems and architectures.
- The nature of the description, static (forms and structures) or dynamic (behaviors and functions).
If Object Oriented approaches are the option of choice for the design of software components, they may fall short when business domains have to be shared across architectures. At that level services oriented approaches seem better adapted; hence the benefits of aspects as a modelling bridge between objects and service oriented paradigms.
Anchoring Persistent and Execution Units
Computer systems are meant to manage symbolic surrogates representing business environments, concerns, resources, and operations. Beyond idiosyncratic terminologies, most of modelling methods agree on a dual perspective, one for the description of objects’ structure and semantics, the other for their behaviors and functions. That implicit consensus can be consolidated into a backbone supporting a comprehensive and consistent identification (#) of systems persistent and execution units vis-à-vis their business environments:
- Symbolic representations of targeted objects, physical or otherwise, are identified with regard to their counterparts within contexts and assembled into architectures.
- Symbolic representations of behaviors are defined with regard to activities and assembled into processes identified by events and time-frames.
That distinction between functional and structural containment can then be used to define and manage the responsibilities of organizational units on business domains.
Responsibilities & Domains
While the representation of business context is supposed to be shared by all business units, the concerns of individual units are by nature specific and domains are introduced to manage the identification and/or semantics of respective symbolic representations:
- Business objects (aka entity) domains deal with the persistent representation of objects whose continuity and consistency have to be managed across domains, independently of activities (a).
- Functional domains deal with shared features whose semantics have to be consistently managed across domains, independently of identities (b).
- Business process domains deal with the representation of processes whose execution must enforce the integrity of persistent objects independently of domains (c).
- Application domains deal with the representation of activities whose footprint during execution can be circumscribed (d).
Yet, to be of any use, that distribution of responsibilities across domains has to be congruent with the definitions of structural and functional elements. And that can be achieved by introducing aspects.
Domains & Aspects
Requirements analysis is meant to start with activities grounded in actual business contexts and conclude with a consolidated symbolic descriptions of systems behaviors. For that purpose the first objective is to identify the execution and persistent units that will be used to tie up systems to contexts, and to allocate responsibilities respectively to entity (a) and functional (c) domains. Execution and persistency backbones can then be fleshed out iteratively with features, some structural (a,c), others detachable (b,d).
Aspects are to be introduced as a level of indirection between persistent (object) and transient (application) domains:
- Objects-based aspects regroup features whose semantics are bound to a specific business object domain.
- Application-based aspects regroup features whose semantics are bound to a specific business process domain.
- Features-based aspects regroup features whose semantics are set by context.
Assuming that persistent and execution units are solidly anchored to contexts by continuous and consistent identification mechanisms, the next step is to proceed with the description of variants between domains and variations along time.
Structures & Variants
Specialization and Generalization are the primary mechanisms used by Object Oriented approaches to deal with variants and variations, the former adding specific features, the latter factoring out shared ones.
To begin with, variants are best introduced by static or dynamic partitions (“2”) respectively of activities (e.g branches or extension points) and objects (classifications or power types). Both kind of partitions can be unequivocally qualified as structural or functional, the former being applied to subsets of persistent or execution units, and therefore exclusive, the latter being applied to features, possibly with overlapping. Partitions can then be used to detail variants in terms of specialization and generalization, and inheritance links added between descriptions.
Structural inheritance (black triangles) is used for structural partitions, i.e when specialization (or generalization) is bound to identities (#) of persistent or execution units. Functional inheritance (white triangles) is used for the specialization (or generalization) of features independently of the objects or activities they describe.
As it happens, those inheritance and structure patterns can be mapped to requirements:
- Use case: composition of activities describing parts of processes supported by systems. As such use cases are identified by their triggering events and associated contexts.
- Scenario: aggregation of activities describing logical sequences of operations. Scenarii can be seen as variants glued together by extension points, or as aggregates of uses cases.
- Structure: composition of features valued wholly for identified objects. Adding a structure is equivalent to specialization.
- Interface: aggregation of features describing their semantics independently of the units they describe.
Such mapping can then be used as a modelling bridge between requirements and services.
Aspects as Modelling Bridge
As noted above, one of the primary objective of systems analysis is to map actual requirements to symbolic features. That difficulty appears clearly when services oriented architectures are targeted, given that as far as services are considered, modelling constructs like inheritance and objects’ states have no currency.
That pitfall can be overcome by using aspects (bd) when services cannot be uniformly and comprehensively defined from persistent (ab) or execution (cd) units.