On Pies & Skies: Abstraction in Models


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.

Abstraction ladders must be propped up by actual contexts (A. Magnaldo)

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.

Business Context and 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.
Business analyst figure maps from territories, software architects create territories from maps
Business analysts figure models from actual contexts and concerns, software architects specify blueprints for artifacts

Climbing up the abstraction ladder, the objective is to align descriptive models of objects and behaviors with prescriptive models of system artifacts. That can be achieved in three steps:

  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.
Field 1 is too small, field 3 is too large. “Dimensions” has no identity of its own, “Broom” is pointless.

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 .

Domains of Concerns and Business Processes

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).
Business logic and surrogates (#) for objects, processes and pianist .

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).
Climbing down: specialization of features (Move Piano) and surrogates (Solo Concert)

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.

Climbing up: generalization of features only (a), and for both features and individuals (b).

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.

A grip on context and concerns

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

3 thoughts on “On Pies & Skies: Abstraction in Models”

  1. Putcha,
    If models are to be introduced somewhere along the development process (e.g, see Agile and Models for conditions), then they will have to be obtained from requirements (e.g, see Requirements capture). With regard to abstraction you may see The Book of Fallacies.

  2. Remy, I have not read all of it but I see that even requirements can be modeled (IREB BOK has a chapter (6 Model Based Requirements Documentation, on it).

    If you agree that model is a notional representation with a purpose(in which some features of the subject are represented with more precision than others for the sake of communication and analysis) business requirements and system capability specifications can also be modeled.

    The word “abstraction” is often used. What is the specific meaning of abstraction that is applied to modeling? What does high or low level of abstraction do to modeling? What levels of abstractions should be used for different purposes?

Leave a Reply

%d bloggers like this: