The development of concurrent object-based programmig languages has suffered from the lack of any generally accepted formal foun ion for de finn their semantics. Furthermore, the delicate relation p between object-oriented features supportin reuse an operation features con n g in teraction a n state chan is poorlyun rstood in a con urren t settin To address this problem, we propose the developmen t of an object calculus, borrowi n heavily from relevan t work in the area of process calculi. To this en we briefly review some of this work, we pose some i ormal requiremen ts for an object calculus, an we present the syntax, operation seman tics an use through examples of a proposed object calculus, called OC.

In this paper we study the fragile base class problem. This problem occurs in open object-oriented systems employing code inheritance as an implementation reuse mechanism. System developers unaware of extensions to the system developed by its users may produce a seemingly acceptable revision of a base class which may damage its extensions. The fragile

this article was given at ECOOP '93.

Formal methods are necessary in achieving correct software: that is, software that can be proven to fulfil its requirements. Formal specifications are unambiguous and analysable. Building a formal model improves understanding. The modelling of nondeterminism, and its subsequent removal in formal steps, allows design and implementation decisions to be made when most suitable. Formal models are amenable to mathematical manipulation and reasoning, and facilitate rigorous testing procedures. However, formal methods are not widely used in software development. In most cases, this is because they are not suitably supported with development tools. Further, many software developers do not recognise the need for rigour. Object oriented techniques are successful in the production of large, complex software systems. The methods are based on simple mathematical models of abstraction and classification. Further, the object oriented approach offers a conceptual consistency across all stages of soft...

Most of today’s dynamic analysis approaches are based on method traces. However, in the case of objectorientation understanding program execution by analyzing method traces is complicated because the behavior of a program depends on the sharing and the transfer of object references (aliasing). We argue that trace-based dynamic analysis is at a too low level of abstraction for objectoriented systems. We propose a new approach that captures the life cycle of objects by explicitly taking into account object aliasing and how aliases propagate during the execution of the program. In this paper, we present in detail our new meta-model and discuss future tracks opened by it. 1

Understanding sets of classes, or packages, is an important activity in the development and reengineering of large object-oriented systems. Packages represent the coarse-grained structure of an application. They are artefacts to deploy and structure software, and therefore more than a simple generalization of classes. The relationships between packages and their contained classes are key in the decomposition of an application and its (re)-modularisation. However, it is difficult to quickly grasp the structure of a package and to understand how a package interacts with the rest of the system. We tackle this problem using butterfly visualizations, i.e., dedicated radar charts built from simple package metrics based on a language-independent meta-model. We illustrate our approach on two applications and show how we can retrieve the relevant characteristics of packages.

Protection of digital data from unauthorized access is of paramount importance. In the past several years, much research has concentrated on protecting data from the standpoint of confidentiality, integrity and availability. Software is a form of data with unique properties and its protection poses unique challenges. First, software can be reverse engineered, which may result in stolen intellectual property. Second, software can be altered with the intent of performing operations this software must not be allowed to perform. With commercial software increasingly distributed in forms from which source code can be easily extracted, such as Java bytecodes, reverse engineering is becoming easier than ever. Obfuscation techniques have been proposed to impede illegal reverse engineers. Obfuscations are program transformations that preserve the program functionality while obscuring the code, thereby protecting the program against reverse engineering. Unfortunately, the existing obfuscation techniques are limited to obscuring variable names, transformations of local control flow, and obscuring expressions using variables of primitive types. In this paper, we propose obfuscations of design of object-oriented programs. We describe three techniques for obfuscation of program design. The class coalescing obfuscation replaces several classes with a single class. The class splitting obfuscation replaces a single class with multiple classes, each responsible for a part of the functionality of the original class. The type hiding obfuscation uses the mechanism of interfaces in Java to obscure the types of objects manipulated by the program. We show the results of our initial experiments with a prototype implementation of these techniques. In particular, we show that the runtime overheads of these obfuscations tend to be small. 1

Understanding packages is an important activity in the reengineering of large object-oriented systems. The relationships between packages and their contained classes can affect the cost of modifying the system. The main problem of this task is to quickly grasp the structure of a package and how it interacts with the rest of the system. In this paper we present a top-down program comprehension strategy based on polymetric views, radar charts, and software metrics. We illustrate this approach on two applications and show how we can retrieve the important characteristics of packages.

Abstract not found

Object orientation seems to provide a welcoming framework for software reuse. This software is typically in the form of individual classes, and the reuse is typically obtained through composition and inheritance. In this paper we address the reuse of stand-alone applications, without modifications, as components in other applications. We do this in the TOOL programming system, taking advantage of its handling of asynchronous messages at the class level. KEYWORDS AND PHRASES object orientation, asynchronous message, software reuse, GUI application, class, interface-implementation decoupling 1 On the Reuse of Object Oriented Applications as Components INTRODUCTION The ability to reuse a known piece of software in the construction of a new program has long been recognized as one of the main goals in the software engineering discipline [1, 2]. Object orientation (OO) seems to provide a welcoming framework for software reuse [3]. Encapsulation, genericity, abstraction and inheritance, ...