Levels and Layers
As a cognitive process, abstraction is not a panacea but comes with a purpose, has to meet some concern. Set in a context, given a situation, symbolic representations must consider relevant features and ignore noisy ones. As a corollary, whereas actual situations may be described by different layers of abstraction, each concern will have its proper level, where relevant aspects can be efficiently characterized, selecting all what is needed, and nothing more.
Applied to system engineering, modeling layers must meet explicit rationale, avoid a “flight to abstraction”, and set for a level adapted to its purpose.
Abstraction and Models
Modeling is all about abstraction, but abstraction comes under different guises. That can be illustrated by the various semantics associated with generalization and specialization: some referring to formal constructs (Set Theory), some to pragmatic (possibility for artifacts to be instantiated), some to programming (partial implementation).
As it happens, those distinctions coincide with model layers and therefore should be relevant to model validation.
To begin with the end, there is not much to add about abstraction in design models since abstraction and inheritance mechanisms are fully defined by programing languages.
Back to beginnings, requirements models are meant to deal with actual business objects and processes, before their symbolic representation by system components being considered. And there is nothing conceptual about business objects or processes, physical or not. Looking for conceptual models at such an early stage would bypass the analysis of symbolic representations. That could be a significant source of errors, and in any case it’s like putting the cart of modelling before the horse of requirements.
And since it doesn’t make sense to speak of partial implementation when programs are still well beyond the horizon, it’s a safe bet to use only subsets and partitions when variants of business objects or activities are to be described.
Modeling Purposes:Prescription or Description
Finally, analysis models appear as the real hub of the modeling process. Sitting between actual descriptions and symbolic implementations, analysis models are explicitly dedicated to the description of symbolic representations. Some of those artifacts will be set, and mapped to, business extensions, while others will be introduced as abstractions.
Abstract artifacts are elements of analysis models which don’t have extensions, i.e which cannot be mapped into actual business counterparts. As such, they are meant to represent some fundamentals of the corporate identity and business concerns whose persistency and consistency has to be maintained by the system architecture. Contrary to technical architecture, this functional architecture don’t deal with resources but with the identification and semantics of business objects and processes.
Upstream abstract artifacts are based upon roles or partitions or created directly through generalization or specialized within analysis models. Downstream, after being mapped into analysis patterns, they will provide the basis of design patterns.
Further Readings
- Thread: Abstractions
- Modeling Paradigm
- Finding Pies in the Skies: Abstraction in Models
- Abstractions & Emerging Architectures
- Modeling languages: differences matter