Abstract. Program errors are hard to find because of the cause-effect gap between the time when an error occurs and the time when the error becomes apparent to the programmer. Although debugging techniques such as conditional and data breakpoints help to find error causes in simple cases, they fail to effectively bridge the cause-effect gap in many situations. Dynamic query-based debuggers offer programmers an effective tool that provides instant error alert by continuously checking inter-object relationships while the debugged program is running. To speed up dynamic query evaluation, our debugger (implemented in portable Java) uses a combination of program instrumentation, load-time code generation, query optimization, and incremental reevaluation. Experiments and a query cost model show that selection queries are efficient in most cases, while more costly join queries are practical when query evaluations are infrequent or query domains are small. 1.

Abstract not found

Measurement systems are of increasing importance for manufacturing, due to high automation level of production processes. Although most measurement systems have much in common and are expensive to construct, these systems are often developed from scratch, hardly reusing the available designs and implementations. To address this, we have designed and implemented an object-oriented framework for the domain of measurement systems that can be used as the core of measurement systems. Evaluations of the framework show that it captures the main concepts in the domain and that the required extensions for individual applications are limited. In this paper, a number of example framework instantiations are presented. The lessons we learned during the framework design and an evaluation of the object-oriented modelling paradigm are presented. 1

Classes are harder to subclass than they need be. This report addresses this problem, showing how to design classes that are more modular and easier to subclass without sacrificing the extensibility that makes subclassing useful to begin with.

does not discover the world by learning abstract rules. Instead it learns by looking at concrete examples. An example contains the rules as well. In contrast to rules, the recognition of examples can be based on tangible reality. The knowledge extracted from an example serves as a Pattern that is used to remember facts and to construct new solutions. When grown-ups are about to learn something or have to apply unknown tools, they are put into a child’s position again. They will favor concrete examples over abstract rules. The rules will happily be generated automatically, for this is how the brain works.

Factory. While this hides the creation process from the client, it doesn't clarify what happens behind the factory interface; you might still have to write a big case statement to distinguish between the different value types. It is much better to go to some object and ask it to return an instance of a DomainWidget subclass which fits a given value type best. This object might be the abstract DomainWidget class itself, or a factory object or a trader object. We call this pattern Product Trader and it is all about how to do this flexibly and efficiently. Suppose, DomainWidget offers a class operation that lets you do this. In C++, it looks like static DomainWidget* DomainWidget::createFor(DomainValue*); and in Smalltalk it looks like DomainWidget class>>createFor: aDomainValue. Internally, the widget class might maintain a dictionary of all its subclasses which it indexes with the class representing a given value type. createFor can be easily implemented then: The DomainWidget class...

Abstract not found

Reengineering an object oriented software system requires some analysis of the existing system. This paper describes, how a combination of complexity and coupling metrics can be used to make such an analysis more focused and thus more effective: the metrics are used to identify the key classes of a system, i.e. classes that structure the system and implement its most important concepts --- understanding them and their collaborations is a good basis for every reengineering task. The paper is intended to be particularly helpful for practitioners, therefore it focuses on practical experiences that have been made with various case studies.

During the development of Beyond-Sniff, a distributed multi-user development platform, we were confronted with various, apparently unrelated problems: data, control, and user interface integration of distributed components, system configuration, user specific preferences, etc. Undoubtedly, it is not trivial to find solutions for such issues, but C++ makes it even more challenging due to its static nature and insufficient metainformation. To overcome these shortcomings, we implemented a small and powerful framework called Any. The Any framework augments C++ with a flexi- ble, dynamic, garbage-collected data representation mechanism. It serves as a language-independent data integration vehicle and provides data management and declarative retrieval facilities.

During the last seven years we developed Sniff and Beyond-Sniff. Sniff is a single-user, one-process programming environment that was implemented on top of the ET++ application framework. Beyond-Sniff is an environment for cooperative software engineering. It consists of a component bus and an open set of seamlessly integrated components (services and tools). In this article, we present the framework specific experience gained in developing Sniff and Beyond-Sniff from the architecture’s perspective as well as the development process ’ perspective. By discussing the architecture we show that Beyond-Sniff consists of a layered system of frameworks. The smaller frameworks consist of a few classes while the larger ones are component-collaboration frameworks comprising building blocks, application frameworks, and components. Based on our experience we argue that componentcollaboration frameworks and layering come naturally for systems with a similar degree of distribution because they make it easier to handle the overall complexity. The iterative development of powerful distributed frameworks can be very expensive if the components are coupled too closely. Our experience shows that flexible coupling mechanisms, allowing for slippage between the components, and tool support can considerably reduce the costs of iterations. 1