Birger Møller-Pedersen

Virtual classes: a powerful mechanism in object-oriented programming

The notions of class, subclass and virtual procedure are fairly well understood and recognized as some of the key concepts in object-oriented programming. The possibility of modifying a virtual procedure in a subclass is a powerful technique for specializing the general properties of the superclass. In most object-oriented languages, the attributes of an object may be references to objects and (virtual) procedures. In Simula and BETA it is also possible to have class attributes. The power of class attributes has not yet been widely recognized. In BETA a class may also have virtual class attributes . This makes it possible to defer part of the specification of a class attribute to a subclass. In this sense virtual classes are analogous to virtual procedures. Virtual classes are mainly interesting within strongly typed languages where they provide a mechanism for defining general parameterized classes such as set, vector and list. In this sense they provide an alternative to generics. Although the notion of virtual class originates from BETA, it is presented as a general language mechanism.

Adding Standardized Variability to Domain Specific Languages

We show how a common language of variability can be used to enhance the expressiveness of a domain specific language (DSL). DSLs have been proposed as a mechanism for expressing variability. Variability between models in a given domain or of a family of systems is captured by language constructs, implying that all possible models in this language are the allowed variations. We explore the possibility of expressing variability in a language independently of the base modeling language. We explore how this works for small DSLs as well as for general purpose languages like UML. Implications of this approach are that the variability language can be standardized, and that DSLs do not have to include variability mechanisms.

Abstraction mechanisms in the BETA programming language

The BETA programming language is developed as part of the BETAproject. The purpose of this project is to develop concepts,constructs and tools in the field of programming and programminglanguages. BETA has been developed from 1975 on and the variousstages of the language are documented in [BETA a]. The application area of BETA is programming of embedded as wellas distributed computing systems. For this reason a major goal hasbeen to develop constructs that may be efficiently implemented.Furthermore the BETA language is intended to have a few number ofbasic but general constructs. It is then necessary that theabstraction mechanisms are powerful in order to define morespecialized constructs. BETA is an object oriented language like SIMULA 67([SIMULA]) and SMALLTALK ([SMALLTALK]). By this is meant that aconstruct like the SIMULA class/subclass mechanism is fundamentalin BETA. In contrast to SMALLTALK, BETA is a language in the ALGOL60 ([ALGOL]) family. SIMULA 67 is a system description and a programming language.The DELTA language ([DELTA]) is a system description language only,allowing description of full concurrency, continuous change andcomponent interaction, developed from a SIMULA conceptual platform.BETA started from the system concepts of DELTA, but is aprogramming language, drawing upon a large number of contributionsto programming research in the 1970s. A basic idea in BETA is tobuild the language upon one, general abstraction mechanism --- thepattern ([BETA a 77]) --- covering both data, procedural andcontrol abstractions, substituting constructs like class,procedure, function and type. Correspondingly objects, procedure activation records andvariables are all regarded as special cases of the basic buildingblock of program executions: the entity. A pattern thusdescribes a category of entities with identical structure.An entity consists of a set of attributes and anaction-part. An attribute may be a data-item or apattern. The action-part is a sequence of imperatives that may beexecuted. A data-item may be an entity or a reference to an entity.A pattern may be used in a procedure like manner in the sense thatan entity (procedure activation record) described by the patternmay be generated and executed as a part of the action sequence ofanother entity. A pattern may be used to generate entities thatexecute their action-part in concurrency with other entities. Suchentities may also execute their actions interleaved in a coroutinelike manner. Entities may be organized hierarcically by means of ageneralization of the SIMULA subclass mechanism. This givespossibilities for grouping common properties of entities ofdifferent patterns. In SIMULA 67 a class may have virtual attributes(procedures, labels, and switches). This is a powerful parametermechanism that gives the possibility to delay the specification ofan attribute to a subclass specification. However, SIMULA 67 lacksthe possibility to have virtual class attributes. Furthermore it isnecessary to have a runtime check on the parameters of virtualprocedures, since it is not possible to specify the parameter listof a virtual procedure. The virtual patterns of BETA is ageneralization of the virtual concept in SIMULA 67. In this paper the sequential part of BETA will be presented. Themain purpose is to demonstrate the use of the pattern/subpatternmechanism with virtual patterns as a powerful abstractionmechanism. In addition, a further generalization of the virtualconcept based on syntactic categories will be described. Work has been initiated to design and implement an integratedprogramming system for BETA. The approach to separatecompilation of BETA modules is described in [BETA c]. This paper is organised as follows: Section 2 describesentities, patterns and imperatives. Section 3 describes thesubpattern mechanism. Virtual patterns are described in section 4.Section 5 describes the generalization of the virtual concept. Insection 6 the remaining elements of BETA not mentioned in theprevious sections are described. Finally the syntax of BETA isgiven in the appendix. Each section with a brief introduction ofthe relevant language elements whereafter a number of examples aregiven. Most of the examples are extended versions of HoaresSmallIntSet [Hoare 72]. There is a distinction between the base language (calledbasic BETA) and standard BETA. Standard BETA is basicBETA extended with a number of commonly used constructs. Theseadditional constructs may all be regarded as patterns in basicBETA, but will often be given a special syntax. This paper willmainly focus on basic BETA. Occasionally we shall use parts of astandard BETA, but this will be stated at the appropiate place.

Consolidated Product Line Variability Modeling

In this chapter we present an improved and simplified metamodel for product line variability. This model has been consolidated from diverse approaches in the earlier research projects ESAPS, CAF and other existing work, supplied with recent research in FAMILIES. The consolidated metamodel aims to be the starting point for standardization. A standard will lay the grounds for commercial and open-source tool support. We present here a prototype tool based on the metamodel. To put the work in context, we present three different approaches for capturing variability: using standard languages (exemplified by UML 2.0), using annotations to standard languages, and using domain-specific languages. We use the same Watch example to present how variability is handled in all three approaches.

What object-oriented programming may be - and what it does not have to be

A conceptual framework for object-oriented programming is presented. The framework is independent of specific programming language constructs. It is illustrated how this framework is reflected in an object-oriented language and the language mechanisms are compared with the corresponding elements of other object-oriented languages. Main issues of object-oriented programming are considered on the basis of the framework presented here.

Developing a software product line for train control: a case study of CVL

This paper presents a case study of creating a software product line for the train signaling domain. The Train Control Language (TCL) is a DSL which automates the production of source code for computers controlling train stations. By applying the Common Variability Language (CVL), which is a separate and generic language to define variability on base models, we form a software product line of stations. We discuss the process and experience of using CVL to automate the production of three real train stations. A brief discussion about the verification needed for the generated products is also included.

Comparison of Three Model Transformation Languages

In this paper we compare three model transformation languages: 1) Concrete syntax-based graph transformation (CGT) which is our emerging model transformation language, 2) Attributed Graph Grammar (AGG) representing traditional graph transformation, and 3) Atlas Transformation Language (ATL) representing model transformation. Our case study is a fairly complicated refactoring of UML activity models. The case study shows that CGT rules are more concise and requires considerably less effort from the modeler, than with AGG and ATL. With AGG and ATL, the transformation modeler needs access to and knowledge of the metamodel and the representation in the abstract syntax. In CGT rules on the other hand, the transformation modeler can concentrate on the familiar concrete syntax of the source and target languages.

Rationale and tutorial on OSDL : an object-oriented extension of SDL

Abstract The paper presents OSDL, an object-oriented extension of SDL. SDL is an acronym for Specification and Description Language. It is recommended as the standard specification language for telecommunication purposes by the International Telecommunication Union CCITT. The paper gives an introduction and overview of object-orientation in general. The object-oriented features of OSDL is presented in the form of a tutorial. It is demonstrated, that by a few extensions SDL becomes object-oriented. At last the rationale for object-orientation in general and OSDL in special is given.

The when, why and why not of the BETA programming language

This paper tells the story of the development of BETA: a programming language with just one abstraction mechanism, instead of one abstraction mechanism for each kind of program element (classes, types, procedures, functions, etc.). The paper explains how this single abstraction mechanism, the pattern, came about and how it was designed to be so powerful that it covered the other mechanisms. In addition to describing the technical challenge of capturing all programming elements with just one abstraction mechanism, the paper also explains how the language was based upon a modeling approach, so that it could be used for analysis, design and implementation. It also illustrates how this modeling approach guided and settled the design of specific language concepts. The paper compares the BETA programming language with other languages and explains how such a minimal language can still support modeling, even though it does not have some of the language mechanisms found in other object-oriented languages. Finally, the paper tries to convey the organization, working conditions and social life around the BETA project, which turned out to be a lifelong activity for Kristen Nygaard, the authors of this paper, and many others.

Exploring the use of Package Templates for flexible re-use of Collections of related Classes

It has been recognized that there is a need for a language mechanism that support reuse of collections of related classes. Existing approaches either use an enclosing class for this purpose, or introduce a special purpose, new language construct. In this paper we explore the use of packages for the grouping of related classes. Ordinary packages are already grouping of classes, so we explore the combination of packages and templates, i.e. package templates. By instantiating package templates, the classes of the package templates are provided as if ordinary packages are produced and imported.