Frameworks: the future of formal software development?

Abstract

It could be argued that the primary issue to be dealt with in software engineering today is re-use of software. Current software development rarely, if ever, starts from nothing. Unfortunately, the same cannot be said for the development of specifications. To overcome this problem, various works have attempted to show how specifications can be built using architectural principles. We discuss one such approach in particular, the Architectural Semantics of Open Distributed Processing. We show the limitations of this work with regard to the architecting of specifications and propose a new approach, based on frameworks. To highlight the approach we use the work currently being done in the TOSCA project in its development of a service creation and validation environment for telecommunication services.

Introduction

The development of software for open distributed systems is a complex activity. There are a multitude of issues that have to be addressed to ensure that the subsystems of the system under development interwork correctly to achieve their goals. Remoteness of software, potential for partial failure, concurrency, language and system heterogeneity are just some of the many direct problems facing distributed systems developers.

Whilst current technologies such as CORBA [2]have addressed many of the issues in remoteness and heterogeneity of languages and systems, such technologies fall short of being the final solution to building truly open distributed systems. To justify this, it is worth noting exactly what is meant by an open system since numerous interpretations of this term exist in the context of distributed systems. Leopold et al. [5]identify several definitions that can be considered as correctly interpreting the term open as found in distributed systems literature:

• an environment and its model are easily obtainable and well documented;

• the model and environment exist on many operating systems and work with many programming methodologies and languages;

• several manufacturers support and control the market;

• the environment and its model are developed after open debating.

We regard the openness of a distributed system as the extendability of that system. That is, how new resource-sharing systems can be added to a system without disrupting existing services. Typically this is achieved through making available the descriptions of specific entry points (interfaces) into the system. From these, it should be possible to add new (possibly heterogeneous) hardware and software to the system.

Recent areas of research 1, 7into open distributed systems are replacing the notion of interconnectivity of computers by interworking of enterprises. We note the distinction between these two concepts as they pertain here. Interconnectivity of computers can be regarded as the ability of computers to communicate successfully with one another. This might be realised, for example, through ensuring that they use similar communication protocols as might be found in the Open System Interconnection (OSI) reference model [12]. Interworking is wider in scope than message passing capabilities though. That is, whilst communication is essential for the successful interworking of separate enterprises, it is only a basis on which the interworking can be established. Interworking may thus be regarded informally as the integration of enterprises to achieve some commonly agreed goal.

The fundamental problem that must be overcome to develop truly open distributed software is one of semantics. Current technologies such as CORBA, are limited by the fact that their openness is defined largely in terms of syntactic aspects of systems, namely by interface definition languages (IDL). Whilst this allows the issues of implementation language and system heterogeneity to be overcome, the approach does not lend itself to building truly open systems according to the above definition. Rather, the approach lends itself to interconnectivity as opposed to interworking issues.

To overcome this problem it is essential that behavioural aspects of systems are dealt with.¹ Formal modelling languages offer a means whereby behaviour can be expressed both precisely and concisely. Unfortunately such techniques are not widely exploited throughout the software engineering community, or at least not as much as we would advocate. There are numerous arguments put forward to reject such techniques—although proposals for improved techniques for expressing behaviour and semantics as precisely or concisely are rare. One of the these that we try to address in this paper, is the actual difficulty in developing specifications.

Various works have been proposed and investigated to overcome this difficulty. One of these was the Reference Model for Open Distributed Processing (ODP-RM) 8, 9. These documents describe semantics in a rigorous although informal manner using stylised natural language. Natural language is limited for specifying semantics though, especially when complexity increases. ODP recognised this and advocated the use of formal description techniques. The Architectural Semantics 10, 11was the result of this endorsement. The initiators of the Architectural Semantics identified numerous potential advantages for the work which we briefly discuss in Section 2.1. One of these was that it would allow a structured (architectural) approach to developing specifications of open distributed systems. Whilst this idea of architecture based specification is an appealing one 4, 13, 14, the Architectural Semantics work fell short of completely fulfilling this goal. We discuss the issues related to this shortcoming in Section 2.1and then propose a similar but more prescriptive approach based on the idea of frameworks. In particular we focus on the development of frameworks based on the Telecommunications Information Networking Architecture (TINA) in the context of the TOSCA project.

The rest of the paper is structured as follows. Section 2gives an overview of the architectural semantics and its advantages and, especially with regard to this paper, its limitations. Section 3introduces the concept of a framework and argues that they offer a means whereby the intention of the architectural semantics in terms of specification development can be realised. Section 4looks at the requirements placed upon formal languages if they are to be used to successfully model frameworks. Section 5highlights how this approach is being adopted in the TOSCA project. Finally Section 6draws some preliminary conclusions on the viability of frameworks as a mechanism for producing software in a formal manner.