A less concrete model of abstraction: PLAM!

I present to you:
the Practical Levels of Abstraction Model

While there are many ways to think about abstraction, many of the accepted models pursue the most concrete definitions possible—something I've always found ironic, given the whole idea of abstraction.

Most existing models for data abstraction describe the disconnect between physical reality and the representation thereof. Which makes perfect sense in the most general way: machine code is less abstract than assembly language, which is less abstract than uncompiled source code; and one could easily compare different programming languages, arguing that Haskell is more abstract than C++, which is more abstract than Fortran, and so forth.

But what about abstraction in the sense of object-oriented programming?

When it comes to writing a program, there is a trade-off for the overall usefulness of code, between two things: how portable you make your solution, and how integrated you make it, with the concrete details of its specific implementation.

In this article, I'll walk you through the Practical Levels of Abstraction Model—PLAM for short. And then I will teach you to use PLAM as a tool for decision making in the software design process.

Red to Blue: Levels of PLAM

According to the PLAM model, there are five levels of abstraction. They are, from bottom to top, "Non Abstract, Fully Integrated," "Partially Abstract, Fully Integrated," "Abstract & Integrated," "Fully Abstract, Partially Integrated," and "Fully Abstract, Non Integrated."  The bottom two levels represent different levels of abstraction with an equivalent level of integration, and the top two levels represent different levels of integration with equivalent levels of abstraction.

The bottom-most level is aptly called "Non Abstract, Fully Integrated" (NAFI). NAFI describes a program that is fully integrated with, embedded in, or exclusive to one specific system, to the extent that it cannot be used on another system. NAFI programs tend to be machine-level, and specific to a piece of hardware. Systems and electrical engineers tend to work at this level, designing arithmetic logic units which are perfectly optimized for their purpose and cannot be re-applied without difficulty. In another approach, NAFI programming may also be one in which your entire solution is located in your "main" function—your program is fully integrated into itself, and none of the tasks your program does can easily be moved into another program.

Above this level is the "Partially Abstract, Fully Integrated" (PAFI) level. PAFI describes a program that is fully integrated with or embedded in one specific system, but is abstracted to the extent that it may be used with another system. PAFI programming may be something such as the API for one company's LCD front-panel display drivers: each separate model of display is designed so that its programming fully exploits the system, but each separate LCD display's unique driver still satisfies the same public-facing API. That is, the under-the-hood guts may differ, but they have been abstracted enough such that users can switch from one to another without any difficulty. Another way to think about PAFI programming is one where some tasks are delegated into functions, but as a whole your program's functionality is not highly transferable. PAFI tends to be the ideal for programmers who work with hardware directly, such as those working on embedded systems, or those making test or sensor equipment.

Next, we have the "Partially Abstract & Partially Integrated" level (PAPI). This level tends to be a sweet spot for many application programmers, because PAPI describes a program that both serves its purpose well and can be re-used or re-applied to other jobs. Consider a program whose tasks are big enough justify object-oriented programming, and so while designing your solution you create a small class library to power it. Those classes can easily be used in another program, if applicable, but they are specific enough that their application is not universal.

The last integrated level is the "Fully Abstract, Partially Integrated" level (FAPI). FAPI describes a program which satisfies a general need, and may be optimized for a family of environments, but is not optimized or specific to any one. Many class libraries and frameworks find their homes here, such as AForge. AForge is a .NET framework which specializes in imaging, robotics, and video functionality. It uses things such as Microsoft DirectShow for video capture, meaning it is compatible with any DirectShow-enabled video capture device—and also that it is not compatible with devices which are not. Further, the tasks it can perform, while abstract, also have limited (specialized) application relative to more general libraries such as the .NET framework

Finally, there is the "Fully Abstract, Non Integrated" level (FANI). This level describes programming that is highly applicable and not highly specialized. Consider core libraries for various programming languages, and their range of use: as long as the language itself is supported by a system, you can use pretty much all of the functionality in a framework, and virtually every program made in a particular languages uses its core framework. Additionally, a lot of work students do in their data structures classes winds up being FANI, regardless of the language being used—in fact, a logical and discrete structures class may not even use a programming language, which is entirely non-integrated and fully abstract. This realm is most important to pure computing scientists, as it describes the pure logic of a system rather than any particular application of it.

How to use PLAM in the field

More than a programming specification, PLAM is a framework for thinking about programming and programming specifications. Terminology like this is useful for collaborative software design processes as well as those in a managerial role, as it helps communicate requirements.

In the world of software engineering, one of the most common complaints is that requirements are vague and unclear, and engineers are somehow expected to turn this vague list of needs into a concrete implementation while working with clients to meet their needs. And because clients rarely know what they want, or need—much less how to talk about it in "software engineering speak"—once the job gets to the actual programmers it can be difficult to know whether you're headed in the right direction, in the right ballpark, or even the right game.

Especially if you work in a small company, where the number of engineers may be low and everyone works in a more agile design process, early talks of a software solution will be greatly helped by using PLAM to discuss with clients what they expect to gain from working with your company. For example, clients may want a perfect solution to their one need, and have no need for portability. Other times, they may hope to have a simple solution as well as a class library they can give to their own developers, to work on a more extensive application.

In short, PLAM's primary use is for talking about software on a conceptual level. These terms are probably not terribly meaningful between software engineers, so consider it an interface for translation between a layman's needs and something more engineering-oriented such as the OSI model.

Conclusion

The Practical Levels of Abstraction Model creates an interface for software engineers, between client and engineering groups, to ease the process of design and create a simple and understandable vocabulary for clients to understand and use. PLAM functions also to help software engineers speak with each other on a conceptual level, during the early stages of design or implementation. It can be used with various software engineering models, including waterfall and agile, and is ideal for small companies that work closely with a number of clients and do not have the luxury of flagrantly ignoring customer desires when designing software.