Object-Oriented Technology and Computing Systems Re-Engineering

By H. S. M. Zedan and A Cau

This book delivers the latest developments in object technology and their impact in computing systems re-engineering. Object-oriented programming is here shown to provide support for constructing large scale systems that are cheaply built and with reusable components, adaptable to changing requirements and use efficient and cost-effective techniques.Internationally recognised authorities from Finland, France, Germany, Italy, Poland, Spain, the UK and the USA here record their research and development work on the industrial techniques and structured object-oriented methodologies in forward and reverse engineering of computing systems. This book takes stock of progress of that work showing its promise and feasibility, and how its structured technology can overcome the limitations of forward engineering methods used in industry. Forward methods are focused in the domain of reverse engineering to implement a high level of specification for existing software.The book contains the selected, quintessential content of the first UK Colloquium on Object Technology and Systems Re-Engineering held at Oxford University in 1998. The conference was sponsored by British Telecom Laboratories, EMSI limited and the OOSP Specialised Group of The British Computer Society.

• Delivers the latest developments in object technology and their impact in computing systems re-engineering
• Provides support for constructing large scale systems that are cheaply built and with reusable components, adaptable to changing requirements and use efficient and cost-effective techniques
• Contains the content of the first UK Colloquium on Object Technology and Systems Re-Engineering held at Oxford University in 1998

• Language: English
• Publisher: Elsevier Science
• Release date: Oct 1, 1999
• ISBN: 9781782420613

Book preview

Cornwall

Preface

There are many important and challenging issues in building software systems. Moreover, the complexity of such systems is continuously increasing. This, together with the sobering experience that the difficulty in building such systems grows much faster than their size, makes a disciplined, systematic and rigorous methodology essential for attaining a ‘reasonable’ level of dependability and trust in these systems. In response to this, an intense research activity has developed resulting in the production of several structured and formal development techniques that have been successfully applied in forward engineering such systems. For example, in the field of structured methods, we find SSDM, Yourdon, Jackson, CORE and HOOD whilst formal techniques include assertional methods, temporal logic, process algebra and automata.

Furthermore, object-oriented programming, over the past few years, has been recognised as the best way currently available for structuring software systems. It emphasises grouping together data and operation performed on them, encapsulating the whole behind a clean interface, and organising the resulting entities in a hierarchy based on specialisation in functionalities. In this way, it provides an excellent support for the construction of large scale systems, which can be built cheaply out of reusable components and which can be adapted easily to changing requirements.

To date, object technology has largely been a field of practitioners, who were driven by an intuitive understanding of the important concepts, arising out of the experience of building actual systems. There has been relatively little effort to develop formal theories about these concepts. However, in order for the field to mature, a more formal understanding of the basic concepts is necessary, forming a solid foundation for refinement and further development.

In addition, there exist many software components that are still in use and are in a legacy state. With the advent of new architectures, the need to introduce new functionalities and the improvement in design techniques, there is a strong need for efficient and costeffective techniques to ‘re-engineer’ these components maintaining its continuity of use. The process of re-engineering a system often requires the construction of a higher level abstraction of the system, a process known as reverse engineering; and the development of a new system starting from its higher level of requirement specification (i.e. forward engineering). Recognising the functionality of an existing code is often seen as being the most difficult aspect of the process of re-engineering. To successfully re-engineer a system, we need to identify design decisions, intended use and domain specific details.

In the area of forward engineering, both formal techniques and structured methodologies have been applied. The use of the former in industry is not as widespread as the later but, where they have been applied, the evidence is somewhat encouraging. Recently there have been a healthy activity in integrating both techniques (for example, Yourdon with Z and SSDM with Z) as a means of overcoming some of the limitations of using formal methods generally by industry.

In the domain of reverse engineering, formal methods have also been put forward as a means to extract high level specification of existing software. In practice, these techniques have not been very successful and have hardly gained any support by industry.

This book presents the latest development in Object Technology and their impact in system re-engineering. It is the Proceedings of the Colloquium on Object Technology and System Re-engineering (COTSR) which was held at Christ Church, Oxford University, 6-8 April 1998. The aim of the COTSR is to be a forum that covers all aspects of research and development on object-technology, reuse and system reengineering.

March 1999

Hussein Zedan and Antonio Cau

1

Toward an Object-Oriented Design Methodology for Hybrid Systems

Viktor [e-mail] and André [e-mail],     Technische Universität Berlin, FB 13, Sekr. FR 5-6, Franklinstraße 28/29, D-10587 Berlin, Germany

Matthias [e-mail],     Daimler-Benz AG, Research and Technology, Alt-Moabit 96a, D-10559 Berlin, Germany

Abstract

In this paper, we present an object-oriented approach to the design of hybrid systems using UMLh, a variant of UML for hybrid systems. We introduce the main concepts of UMLh, describe a support tool, and look at their application for the design of a steam-boiler system.

1.1 INTRODUCTION

Hybrid systems are networks of components with discrete and continuous behavior. Typical examples of hybrid systems are physical processes along with their discrete controllers. As such systems are often involved in safety-critical applications, their analysis plays an important role in current research. Three major analysis strategies can be identified: verification, testing, and simulation. Recently, numerous formalisms have been developed for the precise specification of the behavior of hybrid systems; typical examples are Hybrid Automata [2], Extended Duration Calculus [6], and Hybrid CSP [12]. Most of these formalisms are designed to support formal verification. But there is a fundamental problem with the formal verification of hybrid systems: the majority of such systems are not analytically tractable, only for some special types of (in)equation systems do there exist closed solutions and are algorithms known specifying how these solutions can be found. Hence, formal verification can succeed only for a few special types of problems. On the other hand, systematic testing of a hybrid system using physical prototypes or even a real environment is very expensive. Moreover, errors found during unit or integration testing are very expensive to fix. In the case of safety-critical systems, the resources needed for (regression) testing may account for more than 2/3 of the overall development budget. Simulation is therefore an essential analysis method for hybrid systems, especially if it can help to identify errors at an early stage.

The complexity of applications involving hybrid systems continues to grow rapidly. Powerful structuring means are therefore needed to describe such systems. This is one of the reasons why recently proposed simulation languages like Omola [3], Dymola [7], Smile [13], or Modelica [8] all incorporate object-oriented structuring concepts. Another advantage of the object-oriented paradigm is the adequacy of modeling physical components as objects, which leads to model components that are more reusable. The software engineering group at the TU Berlin has proposed an integrated approach to the development of object-oriented simulations of hybrid systems [4]. The main idea behind this approach is to adapt the conventional software-development process to the simulation development. Here we distinguish three main activities: design, model specification, and implementation (Fig. 1.1). The results of these activities are a set of structure diagrams, a precise and complete description of the behavioral model (ZimOO specification), and a model in an executable simulation language (Smile model description), respectively. For the last two phases, we use the object-oriented specification language ZimOO [9] and the simulation language Smile [13]. The interplay between these last two development phases was described in [4].

Figure 1.1 Structure of object-oriented simulation development

In this paper, we concentrate on the first phase. We describe an object-oriented notation and an accompanying methodology for the design of hybrid systems, which are based on UML (Unified Modeling Language [15]). This notation is called UMLh(hybrid UML). UML is becoming a quasi standard in OOD of discrete systems. It integrates many popular notations of OOD, including class diagrams, use-case diagrams, collaboration diagrams, and statecharts. UMLh is still limited to class diagrams, but it is planned to extend it, adapting and integrating other UML concepts for hybrid systems.

So far, little research has been done on the object-oriented design of hybrid systems, the only relevant work, to our knowledge, being the OHMS approach (Object-oriented Methodology for Hybrid Systems) [16]. There are two main differences between OHMS and UMLh. The first is that OHMS uses hybrid automata as a target language. This is a well-known formalism for hybrid-systems specification, but it is not object-oriented. This is not surprising because the main purpose of OHMS is to verify rather than simulate hybrid systems, and a powerful tool (HyTeX) is available for the symbolic verification of linear hybrid automata. As a target language for UMLh we are here using ZimOO, an object-oriented specification language, which was used as a basis for the development of UMLh. However, UMLh could, in principle, also be used in combination with other object-oriented languages for hybrid system modeling. Thus, the full power of object-oriented simulation languages can be exploited in the third development phase. The second difference between the two approaches is related to the class diagrams. OHMS provides only one general notation for a class. It can then be substituted by a hybrid automaton to describe continuous or hybrid behavior, or by a conventional automaton (a finite state machine) when the object represents purely discrete behavior. As different specification means are needed to describe discrete or continuous behavior (a method is really something quite different from a differential equation), we are convinced that — even at the design level — different notations are needed for discrete and continuous classes. UMLh therefore provides notations for three different kinds of classes: discrete, continuous, and hybrid¹.

The paper is organized as follows. In Section 1.2, we introduce the UMLh notation, explaining in particular the different kinds of classes and the relations between them. Section 1.3 introduces the UMLh methodology. A graphical editor for UMLh is described in Section 1.4. In Section, 1.5 we demonstrate the applicability of the proposed approach by designing a small section of a steam-boiler system [1]. Some concluding remarks are given in Section 1.6.

1.2 NOTATION

Object-oriented design languages and methods are becoming increasingly important. They prove very helpful in managing the high complexity of the software-development process. Although practically every OOD book contains numerous descriptive examples urging the reader to view the real world as a collection of objects, a closer look at conventional OOD notations reveals that, while they are very well suited for object-oriented software development, they are only of limited suitability for the development of technical systems with discrete behavior, and they are completely inadequate when dealing with physical systems exhibiting continuous behavior. The reason for this deficiency is quite simple: the object descriptions are based on two key concepts — attributes describing the state of the object, and methods (operations) allowing this state to to be updated at certain discrete points in time. It is obvious that neither the continuous behavior of physical components nor the continuous communication between such components can be properly described using these concepts.

At the beginning of our project, there was no suitable graphical notation for hybrid systems. A new notation, UMLh, was therefore developed. As mentioned above, this notation is based on the Unified Modeling Language (UML) [15], thus ensuring compatibility with well-known methods. The requirements for such a notation were obtained by abstraction from specification languages for hybrid systems. The results of this analysis are the language concepts discussed in the following subsections.

1.2.1 Classes

To begin with, we should point out some semantic differences between conventional discrete artifacts and hybrid ones. This is important because we use a taxonomy similar to that of discrete models.

As in conventional object-oriented models, the class is the key concept of UMLh. A class defines the structure and behavior of a set of objects. In hybrid systems, both are found: discrete objects and objects characterized by continuous behavior. We therefore distinguish between discrete, continuous, and hybrid classes. The latter have a special semantics; they model hybrid objects, which serve to combine discrete and continuous objects. Fig. 1.2 shows the graphical representations of these classes.

Figure 1.2 Notation of classes (top: expanded, bottom: collapsed)

Nontrivial classes may have large extensions, so it is useful to give a collapsed representation as shown at the bottom of Fig. 1.2.

Discrete classes

can be used to model discrete behavior, which is typically found in controllers. They are represented by rectangles, including a name and sets of attributes, control variables, and operations. Names are used to identify the classes throughout the model; they have a global scope.

The set of attributes together with their appropriate types defines the state space of the class. Each attribute may be complemented by an extension const or state, indicating whether the attribute’s value is constant or not. Owing to the communication mechanism between objects, which is discussed later, there is no need for read permissions. Thus, all system objects have read access to the attributes.

The control variables are part of the class interface. They provide ports that are used for an asynchronous exchange of values between objects. The receiving inner discrete object has only read access to the control variables. Their values are changed by other outer objects. Control variables are used for modeling sensoric coupling between continuous and discrete components. It is important to separate control variables from state variables, otherwise external events could potentially violate the class invariant. Control variables are decorated by the suffix ?; this is influenced by Z and ZimOO, which is based on Z notations. But there is an important semantic difference. As discussed below, there is no need to provide parameters for operations of discrete classes. Instead, the control variables are implicit parameters for all operations of the object. Moreover, as explained below, control variables serve to trigger operations.

Operations change the state of a discrete object by changing the values of its state variables. In our approach, discrete objects are independent parallel components that can be externally controlled by control variables only, operations are therefore called from the object itself. As soon as the precondition of an operation is met, it is executed immediately. Obviously, such preconditions depend essentially on the values of the control variables.

Continuous classes

can be used to model components with continuous behavior. The rounded corners of their shapes illustrate the smooth state trajectory. A continuous class is described by a (global) name and sets of attributes, control variables, variants, and (internal) events.

In continuous classes, attributes and control variables play the same sort of role as in discrete classes. The attributes define the state space of the class, the control variables being interpreted as ports which can be used to pass information to a continuous object in order to influence its behavior. Thus, control variables can be viewed here as interfaces to actuators.

Variants can be viewed as higher-level states of a continuous class. They should be used to describe a finite partitioning of the set of valuations of the attributes and the control variables. An example of such a partition are the three different submodels (ice, liquid, steam) for water, depending on the