Wolfgang Pree

Meta Patterns - A Means For Capturing the Essentials of Reusable Object-Oriented Design

There is an undeniable demand to capture already proven and matured object-oriented design so that building reusable object-oriented software does not always have to start from scratch. The term design pattern emerged as buzzword that is associated as a means to meet that goal. Already existing approaches such as the catalog of design patterns of Erich Gamma et al. [5, 6] and Peter Coads object-oriented patterns [3] differ in the applied notation as well as the way of abstracting from specific application domains.

What characterizes a (software) component

The definitions and discussions below were contributed via e-mail. They are arranged by date. The experts, listed alphabetically above, participated in this virtual round table during the first quarter of 1998.

Automated support for software development with frameworks

This document presents some of the results of an industrial research project on automation of software development. The projects objective is to improve productivity and quality of software development. We see software development based on frameworks and libraries of prefabricated components as a step in this direction. An adequate development style consists of two complementary activities: the creation of frameworks and new components for functionality not available and the composition and configuration of existing components.nJust providing adequate frameworks and components does not necessarily yield automation and efficiency of software development. We developed the concept of relations between software components as a foundation for abstraction, reuse and automatic code generation for component interrelationship. Furthermore we suggest to supplement frameworks with an active cookbook consisting of active recipes which guide the software developer in the use of framework elements.nIn this paper our concept of using relations among software components is presented and the active cookbook is illustrated as a means for developer guidance. We created a prototype to demonstrate these concepts.

Framelets—small and loosely coupled frameworks

Not only the design of complex frameworks is hard, but also the reuse of such artefacts. Furthermore, the internal working of different frameworks is usually not compatible so that two or more frameworks can hardly be combined. As alternative we propose framelets as small architectural building blocks that can be easily understood, modified and combined. The paper first discusses the concepts underlying framelets and presents a sample framelet implemented in Java. 1 Why small is beautiful Although object-oriented frameworks are currently one of the most promising approaches to large-scale reuse of software, they have significant problems reported by several authors (e.g., Bosch et al., 1998; Casais, 1995; Fayad and Schmidt, 1997; Sparks et al., 1996; Johnson, 1992; Lewis, 1995): • The design of a framework is hard. Due to the complexity and size of application frameworks, and the lack of understanding of the framework design process, frameworks are usually designed iteratively, requiring substantial restructuring of numerous classes and long development cycles. • The reusing of a framework is hard. A framework conventionally consists of the core classes of an application, and one has to understand the basic architecture of a particular application type to be able to specialize the framework. • The combination of frameworks is hard. Often a framework assumes that it has the main control of an application. Two or more frameworks making this assumption are difficult to combine without breaking their integrity. We argue that the reason for these problems is the conventional idea of a framework as a skeleton of a complex, full-fledged application. Consequently, a framework becomes a large and tightly coupled collection of classes that breaks sound modularization principles and is difficult to combine with other similar frameworks. Inheritance interfaces and various hidden logical dependencies cannot be managed by application programmers. A solution proposed by many authors is to move to black-box frameworks which are specialized by composition rather than by inheritance. Although this makes the framework easier to use, it restricts its adaptability. Furthermore, problems related to the design and combination of frameworks remain. In other words, not the construction principles of frameworks form a problem, but the granularity of systems where they are applied to. The starting point to tackle these problems is the following: If one takes a look at the source code of various software systems, numerous small aspects are implemented several times in a similar way. Thus, framework concepts can be applied to the construction of such small, flexible reusable assets. We call these building blocks framelets. In contrast to a conventional framework, a framelet • is small in size (< 10 classes), • does not assume main control of an application, • has a clearly defined simple interface. The vision is to have a family of related framelets for a domain area representing an alternative to complex frameworks. Thus we view framelets as a kind of modularization means of frameworks. In large scale, an application is constructed using framelets as black-box components, in small scale each framelet is a tiny white-box framework. This issue will be discussed in more detail below. Commonalities between frameworks and framelets Frameworks and framelets have in common that they implement flexible object-oriented software architectures. For this purpose they rely on the constructs provided by objectoriented programming languages. The few essential framework construction principles, as described, for example, by Pree (1996), are applicable to framelets as well. A framelet retains the Hollywood principle characteristic to white-box frameworks: Framelets are assumed to be extended with application-specific code called by the framelet. To illustrate the notion of a framelet we discuss one representative example taken from the GUI-domain and outline some of the implications of this approach. Naturally, framelets are not restricted to the GUI domain. 2 An example: a list box framelet GUIs of many applications provide numerous list boxes together with buttons to add items to the list box, and to modify and remove them. Thus these GUI elements and their interactions have to be implemented again and again. The associated programming task is a typical example of a piece of programming work that can easily be packaged into a small self-contained framework we call list box framelet. Specializations of the list box framelet differ only in the dialog box used for modifying an item. Figure 1 schematically illustrates a sample specialization of the list box framelet. The arrows roughly indicate the interactions between the visible framework components: When the end user presses the Add or Modify buttons the framelet pops up the specific dialog box. In case of pressing the Modify button the dialog box fields contain strings that correspond to the selected item in the list box. Pressing the OK button in the dialog box adds an item to the list or changes an item. Pressing the Remove button removes the selected item from the list. The framelet has to take care that the Modify and Remove buttons can only be pressed if an item is selected.

Product Line Annotations with UML-F

The Unified Modeling Language (UML) community has started to define so-called profiles in order to better suit the needs of specific domains or settings. Product lines1 represent a special breed of systems--they are extensible semi-finished pieces of software. Completing the semi-finished software leads to various software pieces, typically specific applications, which share the same core. Though product lines have been developed for a wide range of domains, they apply common construction principles. The intention of the UML-F profile (for framework architectures) is the definition of a UML subset, enriched with a few UML-compliant extensions, which allows the annotation of such artifacts. This paper presents aspects of the profile with a focus on patterns and exemplifies the profiles usage.

Where is software headed? A virtual roundtable

To find out where software is headed, experts in academia and industry share their vision of softwares future. It is a snapshot in time of where we have been and possibly where we are headed. The subjects discussed are: the desktop; software technology; objects; software agents; software engineering; parallel software; and the curriculum. The results suggest a strong polarization within the software community: a chasm exists between academia and industry. It appears that these two groups share radically different views on where software is headed. The impression is the heavy emphasis on programming languages, operating systems and algorithms by the academic group, in contrast to the clear emphasis on standards and market-leading trends by the industrial group. Academics worry about evolutionary or incremental changes to already poorly designed languages and systems, while industrialists race to keep up with revolutionary changes in everything. Academics are looking for better ideas, industrialists for better tools. To an industrial person, things are moving fast-they are revolutionary. To an academic, things are moving too slowly, and in the wrong direction-they are only evolutionary changes which are slave to an installed base. >

UML-F: A Modeling Language for Object-Oriented Frameworks

The paper presents the essential features of a new member of the UML language family that supports working with object-oriented frameworks. This UML extension, called UML-F, allows the explicit representation of framework variation points. The paper discusses some of the relevant aspects of UML-F, which is based on standard UML extension mechanisms. A case study shows how it can be used to assist framework development. A discussion of additional tools for automating framework implementation and instantiation rounds out the paper.

Self-configuring components for client/server applications

A mechanistic view of software component assembly implies exact matching and fitting of the particular components. We argue that components for large-scale software construction should have automatic configuration capabilities in order to significantly enhance their reusability and maintainability. The paper sketches a pragmatic approach for implementing self-configuring components, relying on framework technology, meta-information and naming conventions. A case study drawn from the client/server domain illustrates the concepts.

Model-Driven Development of FlexRay-Based Systems with the Timing Definition Language (TDL)

This paper argues that a logical specification of the timing behavior, which represents the core abstraction of the Timing Definition Language (TDL), is the key to significantly reduce the development, maintenance and integration costs of FlexRay-based systems. We measured a productivity gain by a factor of 20 and more with TDL compared to state-of-the-art FlexRay development methods and tools (see Section 1). We illustrate how TDL allows the platform-independent modeling of the timing and functional behavior, and how we accomplish the automatic platform mapping. An outlook sketches future research activities.

Ein Wegweiser für Forschung und Lehre im Software-Engineering eingebetteter Systeme

Bisher wurde das Gebiet der Software für eingebettete Systeme („embedded systems”) von der Informatik zu wenig beachtet.