Skip to Content

The steady rise in the abstraction level of software technology platforms over the years has enabled a similar rise in the abstraction level of programming languages and model-driven development tools. In this blog, I explain this synergistic relationship between these two ways of pushing the abstraction level upward. In my next blog, I’ll explain how business process platforms take this synergy to the next level.

The Software Technology Platform: A Brief History

A software technology platform consists of technical infrastructure that provides software capabilities. It frees application developers from having to program those capabilities in each application.

Operating Systems

The first platforms were computer operating systems. Before operating systems, applications directly addressed sectors and tracks on disks when they needed to store and retrieve data, and had to maintain linked lists to keep account of the available free spots where they stored logically contiguous data. Operating systems present the illusion of a contiguous block of data called a file, and keep track of the free spots where virtually contiguous data is stored.

Operating systems gradually became more capable over the years. By the 1970s, there were operating systems that could mediate multi-user access to a processor. Early PC operating systems were primitive compared to the mainframe and mid-range operating systems of the day, but, over time, PC operating systems have grown more capable, and provide additional capabilities such as services for constructing graphical user interfaces.

Database Management Systems

Database management systems (DBMSs) came on line in the late 1970s. Applications no longer had to write their own data sorting and indexing routines. These and other capabilities of the DBMSs dramatically raised the abstraction level for data management, providing a new kind of software technology platform that extends above the operating system.

Network Technologies

Network technologies, such as TCP/IP and IPX/SPX, and remote computing systems, such as SDLC, made it easier for applications that reside on different computers to talk to each other. By providing basic network services they freed applications from having to keep track of how messages are broken up into packets and reassembled, and from other laborious tasks. They provided a platform for distributed computing, adding to the platform stack above the operating system.

Transaction Processing Systems

IMS is the classic, high-volume business transaction processing system. It provides a technology platform at a yet higher level of abstraction. Transaction systems manage the roll back of a partially completed transaction when some part of the transaction fails. A classic example is double-entry bookkeeping, which requires a debit and credit entry for each event entered into the general ledger. What happens when the credit entry fails after the debit is completed (or vice versa)? Transaction processing systems manage this kind of issue.

Latter-day “two-phase commit” transaction monitors have extended the rollback capability to transactions that span multiple databases.

Middleware

The advent of middleware has provided the application developer with yet more capabilities. Middleware takes its name from its positioning between the application and the rest of the platform stack (see Figure 1). Middleware encompasses a number of technologies, including:

  • Distributed computing technologies such as CORBA and RMI, which provide distribution services that are at a higher abstraction level than basic network technologies.
  • Application servers that provide high-level services to applications for managing transactions, persistence, security, resource pooling, and more.
  • Message queue systems for asynchronous messaging among applications
  • Data integration engines, which perform transformations of data from the format required by one application to that required by another application
  • Service integration engines, which mediate disparate data formats and different application program interfaces by encapsulating them with relatively high-granularity, reusable services
  • image
    Figure 1

Computer Languages: A Brief History

At the same time that the abstraction level of software technology platforms has been trending upward, the abstraction level that we use to develop software applications has risen as well.

From Assembly to 3GLs

Early programs were written in 1s and 0s and literally manipulated bits and bytes in registers of the processor and memory addresses. Assembly language made it possible to use mnemonics to refer to registers and memory locations. Third generations languages (3GLs) such as COBOL, FORTRAN, C, and Java raised the abstraction level above the paradigm of the processor. One line of 3GL code can easily correspond to a dozen or more lines of assembly code.

Modeling Languages and Model Compilers

Model-driven approaches to software development, such as the OMG’s MDA® and Microsoft’s Software Factories, are raising the abstraction level still further. They use models crafted with general-purpose and domain-specific modeling languages to specify applications and components, and use model compilers to generate 3GL code. Model-driven approaches to deployment and runtime management are also on the horizon.

The Technology Platform as a Key Enabler for Model-Driven Systems

The rise in the abstraction level of the software technology platform is a key enabler of the model-driven approach. A model compiler would have a more difficult job without higher-level platforms. Imagine a model compiler that had to generate assembly code, and had to do so without the services of an operating system. It is considerably easier to generate Java code that sits on top of an operating system, and easier still to generate Java code that uses J2EE’s plethora of middleware, or to generate C# code that leverages .NET. Figure 2 illustrates the fact that middleware shrinks the abstraction gap between the model and the platform, a gap that the model compilers have to fill in.

image
Figure 2

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

    1. David Frankel Post author
      I’m not sure what you mean when you talk about a system that creates its own abstraction layer.  Can you elaborate a bit?
      (0) 

Leave a Reply