On Pies & Skies: Abstraction in Models

Objective

The value of a model is its fitness to purpose. Missing this simple truth will inevitably trigger a “flight for abstraction” and begets models devoid of any anchor to business relevancy.

Yet, that pitfall can be avoided if requirements and models are put in perspective:

• Requirements are meant to describe systems in their business context, models describe system artifacts. They should not be confused because the former are supposed to be rooted in concrete descriptions, while the latter aim at their abstract representation.
• Models are built from nodes and associations. Nodes refer to instances which are supposed to be uniformly and consistently identified in both business and system contexts; associations may refer to instances (relationships and flows) or classes (specialization and generalization), the former with consistent semantics for business and system realms, the latter with semantics specific to system artifacts.

Along that perspective, the mapping of requirements into models can be achieved by applying selectively the two faces of abstraction: first removing information from the description of actual contexts, then building symbolic representations according to business concerns.

Starting with requirements, the challenge is therefore to move up and down the abstraction ladder until one gets the focus right, providing a clear and sharp picture of business context and concerns.

Models & Semantics

With regard to systems engineering, models’ semantics are unambiguously determined by their target: business environments or systems artifacts:

• Models of business environments describe the relevant features of selected objects and behaviors, including supporting systems. Such models are said extensional as they target subsets of actual contexts.
• Models of systems artifacts specify the hardware and software components of supporting systems. Such models are said intensional as they define artifacts to be created.

1. Awareness of contexts: mind the business pie, drop everything else.
2. Domains of concern: say what features mean.
3. Symbolic representations: consolidate the descriptions of surrogates.

It is worth to note that the first two levels deal respectively with instances and features of actual objects and activities, while the third deal with artifacts. As a corollary, abstraction at the first two levels should be understood in terms of partitions and subsets, with subtypes introduced only for symbolic representations.

Awareness of Context

As illustrated by sounds (filtering noises) or optics (image point), focusing is a basic perceptual task targeting actual instances of objects, events, or activities. With regard to models, it can be achieved with a pronged move:

• Adjust the depth of field to encompass the relevant business context. Large depths of field (aka deep focus) will cover concerns across domains, small ones (aka shallow focus) will support specific business concerns.
• Single out image points for identified objects or activities deemed to be pivotal.

A too shallow focus will capture only some of relevant objects (Piano), activities (Move) or events (Concert). Conversely, extending the focus may go too deep, including irrelevant items (Trumpet, Violinist, Illness, or Repair). Moreover, some image points may depend of others for their identity (Dimensions), or be pointless altogether (Broom).

Domains of Concerns

While business contexts are the same for all, business concerns are by nature specific to domains. The challenge for requirements capture is therefore to anchor specific features to shared objects and activities whose identities are set by business context.

For that purpose concerns are to be organized into domains responsible for the identification of anchors (objects, agents, activities) and the semantics of features:

• Shared domains deal with anchors whose continuity and consistency have to be managed across domains, independently of activities.
• Specific domains deal with anchors whose continuity and consistency can be managed within a single domain.

At this stage the challenge is to distinguish between identified instances of business objects (piano, concert) and processes (cleaning, moving, playing) on one hand, and the description of roles (mover, cleaner, pianist) and business logic (clean, move, play) on the other hand .

It must be reminded that such models are still at ground level as they describe sets of instances; yet, they can also be seen as the first step up the abstraction ladder, as their objective is to extract relevant features and overlook others.

Symbolic Representations

While business concerns are partial and biased, the symbolic representations managed at system level must be comprehensive and consistent; that’s the objective of requirements analysis.

To start with, symbolic representations are introduced for each set of objects, roles or activities:

• Objects surrogates: used to manage the continuity and consistency of business objects independently of business processes (piano, concert).
• Process surrogates: used to manage the continuity and consistency of business operations independently of business objects (move, play, clean).
• Roles: used to manage the interactions between actual agents and system functionalities (mover, cleaner, pianist). When the continuity and consistency of operations performed by agents are managed (e.g pianist), roles must be associated to surrogates.
• Activities: used to describe business logic (move, play, clean).

Those are “flat” descriptions representing ground level instances. In order to be effectively supported by systems, models may have to be expanded downward by specialization, or upward by generalization.

Levels of Abstraction

As already noted, specialization and generalization are not symmetric because, contrary to the former operation, the latter one does modify the semantics of existing artifacts.

The purpose of specialization is to introduce specific descriptions for subsets of instances or features. For instance, assuming requirements are about moving pianos, the representation must climb one step down the abstraction ladder, from concerts to concerts with pianos:

• Solo piano concerts are a subset of concerts subject to the same identification mechanisms and integrity constraints (strong inheritance).
• The description of moving operations is not used to manage instances and its specialization is only about features (weak inheritance).

The purpose of generalization is twofold as it may be limited to features (aka aspect generalization) or targets both identification mechanisms and features (aka object generalization).

Aspect generalization introduces a base artifact for the description for shared features. Such base artifact is said to be abstract because its inheritance is limited to features and it cannot support the instantiation of surrogates, specialized artifacts keeping their own identification mechanisms. As a corollary, the level of abstraction is not modified because the model remains anchored to the same sets of instances. For instance (a), some administrative procedures can be defined uniformly for all maintenance operations otherwise described and executed independently.

That’s not the case with object generalization which redefines the initial sets of surrogates as subsets of newly created super-sets. For instance (b),  a cleaning process becomes a maintaining processes without the repair extension. Since maintaining processes can be created as simple cleaning or repairing ones, the model is anchored to different levels of abstraction. And since descriptions should not cross levels, roles must be specialized similarly: maintainers are to be identified as such before being qualified as mechanics, even if their interventions are not managed as such (inheritance of transient identification mechanism).

Getting A Proper Grip

Models are neither true or false and can only be assessed for consistency and effectiveness.

While verification of internal consistency is best achieved by built-in checks supported by modeling tools, validation of external consistency requires human inspection and assessment of alternatives. Yet neither will guarantee models effectiveness.

Hence, assuming that (1) systems are meant to handle surrogates of business objects and processes and, (2) those surrogates are designed from models,  it ensues that (3) a litmus test of model effectiveness would be the grip it provides on relevant objects and processes.

And that can only be achieved by pinning models to concrete and identified business objects and processes. That provides a template for modeling grips: concrete descriptions with primary identification in the middle, abstract ones above, aspects or concrete descriptions with inherited identification below.

Further Reading

• The Book of Fallacies
• Reflections for the Perplexed
• Languages and Models
• Partitions and Power-types
• Specialization Patterns
• Specialization vs Generalization
• Abstractions and Emerging Architectures
• Open Concepts
• Open Concepts Will Make You Free