- Email: [email protected]
A software engineering environment for distributed applications
North-Holland Microprocessingand Microprogramming 27 (1989) 327-332
327
A SOFTWARE ENGINEERING ENVIRONMENT FOR DISTRIBUTED APPLICATIONS M. Miihlh~iuser1, A. Schill 1, J. Kienh6fer 1, H. Frank2, L. Heuser 2 IUniversity of Karlsruhe, Institute for Telematics, Zirkel 2, D-7500 Karlsruhe, West Germany 2Digital Equipment GmbH, CEC Karlsruhe, Haid-und-Neu-Str. 5, D-7500 Karlsruhe, West Germany With the recent development of powerful workstations integrated in local area networks, the need for distributed applications has increased significantly. This way, formerly autonomous applications of areas like computer integrated manufacturing or office automation can be integrated to cooperating entities. However, the development of these kinds of applications is still not well supported The paper describes an object-oriented software engineering approach for distributed applications. The approach is centered around a wide-spectrum design language used as a common base for a set of workbenches. The associated tools are focusing on problems related to distribution and complexity of applications. Life-cycle spanning development support shall be provided by the environment. Keywords: Computer Aided Software Engineering, Methods and Techniques, Distributed Applications, Object-Oriented Programming, Object Mobility, Object Cooperation, Parallelism, Requirements Engineering.
1.
INTRODUCTION
The ever continuing computerization of our society is presently marked by a growing cooperation and inter-operation of formerly independent and isolated systems, in both hard- and software. As a consequence, the task of computing becomes more and more that of coping with complex distributed systems. In hardware, this trend is speeded up by the rapid deployment of networked workstations and by new communication media which increase communication capacities by orders of magnitudes. In software, a trend to growing integration and cooperation of formerly autonomous applications can be observed in many fields; computer integrated manufacturing, office automation, and information management systems are example domains in which complex distributed software plays a dominant role already today. We call such complex distributed software distributed applications in the remainder, in order to contrast it from operating system level software. We call for appropriate software engineering support - comprising environments, tools, and linguistic aids - for developing distributed applications. The paper describes the project DOCASE - distribution and objects in CASE (computer aided software engineering). It is the intend of DOCASE to help show the way towards environments, tools and languages which are appropriate for distributed programming. In this attempt, we made use of, or had to reflect, other major trends in software engineering:
•
Environments: environment distribution, kernel standardization, and extendibility Due to the fact that programming in the large is more and more carried out in a distributed system with each developer having his own workstation, software engineering environments tend to become themselves distributed. We consider this trend towards environment distribution important, still putting a larger emphasis on application distribution, as described above. The skeleton of software engineering environments - in terms of functions, human interfaces, and data repositories - is currently undergoing a standardization process. Efforts for such standardized environment shells exist in Europe (PCTE, PCTE+) [1] and in the U.S, (CAIS). Extendibility is the attempt to keep an environment open for future extensions (e.g., new tools to come). First approaches, decoupling relevant data definitions and data from individual tools, showed great advances but are still insufficient.
•
Tools: CASEtools and ToolSets. CASEtools support software engineering methods - formerly performed with paper and pencil - on workstations, with a growing level of integration with other tools. The tendency to integrate tools across the software life-cycle leads to ToolSets, where the intend is to provide a 'common look and feel' and easy data sharing among the tools in a set.
M. MDhlh#user et aL / A Software Engineering Environment
328
•
Linguistic aids: object-orientation
and design
support. Object-oriented languages [2,3], with the strong modularity they enforce, proved to help managing complexity, a major problem of distributed applications. The very few existing approaches to distributed object-oriented programming proved that a number of helpful concepts in distributed programming can be easily introduced using the object paradigm (e.g., transparency of the underlying network structure). Design support is provided by so-called wide-spectrum languages coveting the range from high level, incompletely specified early development phases to low level, detailed description of software. The seamless path from early to late phases and the ease of maintenance make this approach very attractive.
HMI-Layer
[DODL-TranslatorI
Functional
ji
Regarding our central goal of distributed application development and the major trends pointed out, we summarize the basic requirements for the DOCASE environment as follows: 1.
Reflect the complexity of distributed applications through design level support and object-oriented linguistic aids.
2.
Provide openness and extendibility
3.
Meet requirements of distributed programming in linguistic aids, in tools, and in the environment.
4.
Provide life-cycle spanning support.
2.
THE DOCASE ARCHITECTURE
NOTE: For the remainder, we refer to the enclosed figure of the DOCASE environment architecture. Shaded parts refer to software parts imported, i.e., not implemented as part of the project. The architecture distinguishes humanmachine-interaction (HMI layer) and data aspects from mainly functional aspects. Parts not described in the remainder (especially in the HMI layer and in the data layer) were left out in the figure.
JRuntirneSystemI
...............................
. . . . . . .G£ . . . .iiiii!iiiii!i. . . . . . . . . . . . .iiiii . . .:!i. . . . . .
DOCASE Kernel Interface
Data Layer
The D O C A S E Architecture 2.1
The semantic center: DOCASE design language - DODL
Object-Orientation: We decided to develop an object-oriented language DODL as the center of distributed application development. Information hiding, uniformity, and inheritance as introduced in the object-oriented approach help coping with distributed application complexity. On the other hand, the uniformity of the object-oriented approach has major deficiencies: tools do not "see" the semantic characteristics of objects (distinguishing, e.g., processes, private and exchanged data, files etc., as with conventional programming). DODL therefore defines a top-level hierarchy of objects known to all tools. In contrast to known object-oriented approaches, we make the differences between a) more stable, "structural" objects, b) more volatile, "moving" objects generated in large quantities, and c) semantic relations between objects visible to tools and developers.
Design Level: DODL also follows the "wide spectrum" paradigm, providing very abstract constructs for a high level description of application stmcture, functional behavior, and communication, which can be further refined in DODL until the implementation level of detail is reached. From there, a transformation into a target (distributed object oriented) language is provided.
Distributed programming: DODL reflects distribution aspects: communication not
M. MShlh#user et al. / A Software Engineering Environment
only occurs implicitly via method calls, but also explicitly via communication relations. In addition, the flow of DODL generated objects (see below) can be explicitly stated. Configuration of objects in a distributed system, including dynamic configuration changes, can be expressed in dedicated configuration sections. Extendibility: A developer can define new object types as subtypes of the DODL top level hierarchy: new predefmed objects, new predefined methods, and language extensions can be defined, and will be reflected in many of the DOCASE standard tools. DODL code is analyzed and precompiled by the DODL translator, translating into an intermediate format. The DODL translator interacts with both the workbenches (see below) and the DODL editor. The latter supports both graphical and alphanumerical views and is one of the principal interaction tools for the user. The open definition of the DODL translator interface allows for extensions (e.g., support for new tools). DOCASE is providing a number of generic design objects applicable through DODL. These objects form a class hierarchy [4] exploiting inheritance. Objects generated from this class hierarchy represent a particular design. They form an arbitrary instance hierarchy describing the overall top-down view of the designed system. The advantage of the explicit top-level hierarchy is that all CASE tools (graphical design aids, runtime visualization tools, etc.) can exploit it. Below, the major classes will be introduced. The DOCASE object is the highest level class. It is an abstract class with different concrete subclasses: the configured objects, the (dynamically) generated objects, and the relation objects. Configured objects are created, deleted and modified by special configuration operations. The distinction of configured (intuitively "visible", more "static") objects and generated (intuitively "shortliving", more "dynamic") objects has been proven to be very close to a software designer's way of thinking. We introduce relation objects in order to represent static and dynamic relations between other objects. The explicit and separate expression of inter-object relations is one of the key issues of DODL. 2.2
The functional center: workbenches
Specific development aspects in DOCASE are handled by DOCASE workbenches. A workbench can be characterized by the following properties: •
Common framework for a collection of tools (cf. ToolSet in chapter 1).
329
•
Orientation towards a common goal related to a specific development aspect.
•
Life-cycle spanning functionality (as far as the development aspect is life-cycle spanning).
•
Uniform, phase independent human-machine-interaction with all tools in the workbench.
•
Integration with DODL representation.
Both the developer and the workbenches are able to reflect their decisions right in DODL syntax, i.e. the DODL representation is providing a common base for all development aspects. Due to the focus of DOCASE on distribution, the following workbenches are currently under development: 2.2.1 Mobility Workbench: Current distributed object-oriented systems only provide basic facilities for object mobility [5,6]. Object migrations have to be stated directly in application code. They are usually focusing on the goal of collocating communicating objects at a common node in order to reduce remote interactions. The direct use of these facilities, however, is associated with a number of problems for the application developer. In large applications, the complexity of determining appropriate object migrations can be significant. From the software engineering point, distribution independent application code is intermixed with distribution dependent mobility instructions. Therefore, we are proposing a higher level, goal oriented approach to control object mobility. It realizes event based decisions concerning object migrations. It is considering a-priori information about expected inter-object communication as well as runtime information including object sizes, current object locations and current object invocations. To represent a-priori information, we introduce a special construct called collocation definition. A collocation definition is used to identify objects to be collocated dynamically. These objects are described by a tree structure built from formal object parameters which are linked by relations. A collocation definition also comprises an initiation event and a termination event controlling the lifetime of its collocations (see below). Relevant events can be method invocations and their return and the creation and deletion of inter-object references. The a-priori information describes the expected future inter-object communication which is caused by a method invocation or which is associated with an inter-object relation. Collocation definitions can be explicitly given by the developer using a special syntax or can be generated by the system by performing call analyses.
330
IV~. M5hlh§user et al. / A Software Engineering Environment
At runtime, a collocation is created as an instance of a collocation definition when its initiation event occurs. Then a distributed algorithm is executed to identify the associated objects, collect theft runtime information and decide about actual object migrations. A logical node to collocate the objects is selected heuristically considering migration costs and mobilityrestrictions. Conflicts between different collocations including the same objects are resolved heuristically, too. Collocations are deleted on occurrence of theft termination event given by the collocation definition. The approach offers different levels of abstraction conceming the problem of mobility control. They are ranging from explicit specification of objects to be collocated up to (limited) automation of migration decisions. A conceptual description tool, a runtime mobility control component and a monitor component realizing our approach have been implemented. They are based on an environment providing an object-oriented emulation of distribution.
port their development. Algorithms are defmed as operations or object cooperations to fulfill a specific task. We distinguish between:
•
Basic algorithms which are provided by objects of the application. They are implemented as operations and are the basic components of the procedural model.
•
Complex algorithms are composed of existing object cooperations and basic algorithms. They define the procedural behavior of sets of objects to perform complex application tasks.
A complex algorithm can be typed and inherit behavior from supertypes. A "create" operation enables the programmer to use several instances of the same algorithm. Like object types in DODL we would like to classify the types of complex algorithms depending on the level of abstraction they provide. The Object Cooperation Workbench will provide a design method and tools which support the development of complex algorithms using the DODL as platform.
2.2.2 Object Cooperation Workbench: The following paragraphs describe the reference model of the Object Cooperation Workbench. The complexity of a distributed object-oriented application could be measured by the number of objects it consists and by the number of threads of control it fires. The first value describes the complexity of the static application architecture, whereas the other one represents the complexity of the dynamic procedural behavior This distinction of software complexity is the basis of the reference model [7]. The procedural model, which is the upper layer of the reference model, provides two views. The operative view figuring the operations of an object has close relationships to the structural model, the lower layer of the reference model. The procedural view presents functional building blocks (tasks) implemented as complex algorithms. In large applications functional building blocks exist which involve operations of many objects. Especially, distributed applications perform complex algorithms due to the distribution of objects. Besides the complexity of the application domain the problem space of reliable execution is taken into consideration. This complex algorithms are representing' real world processes which could not be adapted to any object of the application. In addition, complex algorithms arise a new dimension to the designer's world: Time. Algorithms could stay for a long time within the system. They have to fulfill requirements about their duration and the meantime between service requests and related responds. Therefore, an extension to the structural model is required to treat complex algorithms as independent objects and to sup-
2.2.3 Concurrency Workbench: The concurrency workbench consists of three tools which help the designer using three parallel programruing methods. For achieving reasonable parallelism we combine these programming methods with a special communication structure on processors called backlooped tree. Experiments show that when the potential degree of parallelism is used the speedup grows nearly linearly with the number of processors. The divide-and-conquer approach (d&q) as the first programming method can be parallelized according to the message-passing d&q as described in [8]. Within the tool the designer is able to ftll out a recursive dataflow graph, which shows graphically the d&q algorithm. The layout is then transferred to the DODL language. The second parallelism method is the SIMD approach. It can be seen as a specialization of the d&q approach. It is distinguished from the d&q that only data structures are divided into several pieces. All subdata can now be treated with the same instructions. If the division is carded out with an divisor equivalent to the number of processors in use, the speedup is maximal. In the third programming method the designer uses parallel constructs explicitly. He tells the system which task has to run on which processor and which task communicates with which task. It is possible that messages have to be routed through other processors. This programruing method is supported with a graphical interaction editor, where a dataflow graph can be designed. The mapping from the dataflow graph to the underlying net-
M. MShlh§user et aL / A Software Engineering Environment
331
work is made automatically. According to the number of processors between two communicating tasks (is proportional to log n, n= number of processors in the network), the speedup is nearly equivalent to the number of processors.
•
Implementing all three programming methods with a task-scheduling-mechanism will enable us to generate programs running on parallel processors which communicate over the Optimal Back-Looped Tree. The supporting workbench will be integrated into DOCASE.
During the Requirements Engineering process the workbench requires sets of related requirements as input. Each requirements set describes a specific part of an application. The base of reusable packages is then searched for matching formatted requirements.
2.2.4 Requirements Engineering Workbench: The combination of object-orientation and explicit toplevel structuring introduced in DODL made it feasible to allow for computer assistance in Requirements Engineering [9]. The work steps considered as part of Requirements Engineering hereby are the Requirements Gathering, Requirements Analysis, and Requirements Transformation.
Requirements Gathering is the analysis of the current situation and the identification of the needs for a change. If the decision is made to use computer support to introduce the necessary changes the next step has to be the Requirements Analysis. Here the Requirements Gatherhag is often redone as now the most obvious software and hardware constraints are introduced. The goal of this task is to structure the requirements so that it is possible to analyze the description for missing details. Errors occurring during this step will influence the software development and increase the necessity for cycles during the development process. To gain the first software model out of the Requirements Specification it is necessary to transform the real-world model of the application into a software oriented schema and representation. This step is called Requirements Transformation and forlns the linkage to the Software Engineering process. The goal of the workbench is to support the work steps in Requirements Engineering and to include work steps during the Software Engineering process that are requirements related. The following main support steps are considered: Requirements Engineering - notation for requirements entries - animation for the requirements notation - reusable requirements in the form of software packages + description in the requirements notation - transformation into DODL
Software Engineering identification and isolation of reusable software packages - inclusion into the package base for Requirements Engineering -
If a matching description is found the user can generate an animation to verify the behavioral match to the new application. In the case that the matching process returns several similar matching descriptions, the animation facility is used to verify the best or closest fit for the new application. Applying this process to all requirements and using all available and matching reusables builds a model of the application in the requirements representation plus in a software representation - in this case in DODL. 2.2.5 Importing Workbenches Other development aspects, e.g. project time management, can be handled by importing existing tool sets as external workbenches due to the openness of the kernel interface (see above). Such external workbenches, however, do not necessarily meet all the properties summarized for DOCASE workbenches above. 2.3
The target: runtime environment
DOCASE is not restricted to a single type of mntime environment: several target languages can be envisioned into which DODL will be transformed automatically. Such target languages have to be distributed and objectoriented. Emulated and simulated runtime environments may also be supported. (In fact, up to the point when robust distributed object-oriented languages will be available for the DOCASE project, the iuntime environment for DOCASE will be one with emulated distribution). Command and control access of the workbenches to the environments (e.g. to control and monitor the application execution) is realized through a common command / event interface to be implemented for every target runtime system. The actual transformation is going to be performed by the DODL compiler when an application design has reached a sufficient level of detail. Object class definitions and parts of the executable DODL code can be transformed directly into the code of a distributed object-oriented language. Specific constructs addressing mo-
332
M. MDhll~user et al. / A Software Engineering Environment
bility control (see below) or other higher level support have to be translated into calls to library routines. Appropriate libraries will be provided by the DOCASE kernel. In addition, various kinds of description data given by a DODL design have to be made explicit to the runtime environment. Examples are inter-object relations or application events. This information is extracted by the DODL compiler and is written onto separate files. At runtime, it is loaded and fed into the higher level tools of the DOCASE workbenches. If parts of a DOCASE design are still incomplete or do not provide enough semantic information to generate executable code, they can be annotated by support data from emulation or simulation of the desired behavior Examples are the specification of expected communication delays or of invocation durations. By supporting the transformation step, the well-known gap between design and implementation of an application is filled. This way, the need for re-coding an application in a different implementation language is vanishing. Full support for the generation of very efficient and final code, however, requires intelligent compiler techniques which are currently outside the scope of our project. 2.4
The envelope: kernel interface
The kernel interface defines a general view of DOCASE (including its external workbenches) to standardized environment shells as described in chapter 1. This is realized through the DOCASE kernel interface, consisting of three parts: an interface to the data repository (a realization independent schema defmition with semantic extensions), an interface to the basic functionality (operating system and shell independent system service and shell command definitions), and an interface to the humanmachine-interaction layer (an object library for screen artifacts and input items). Like the command / control interface to runtime environments, the kernel interface has to be implemented for every environment shell to be used with DOCASE. 3.
CONCLUSION
We showed that state of the art software engineering is inappropriate for one of the major challenges in software production of the near future, namely distributed application production. We gave an overview of approaches
in all related fields - linguistic aids, tools, and environments - of software engineering, integrated in the software engineering environment DOCASE and presented short surveys of the current workbenches. At present, the DODL definition is finalized, the ftrst version of the mobility workbench is nearing completion, and the DODL editor and translator are well under way. For the other DOCASE workbenches currently only partial and prototypical realizations exist as their detailed specification is yet in work.
REFERENCES [ 1] Gallo, F., The PCTE initiative: toward a European approach to software engineering, Proc. CRAI workshop on Software Factories & Ada, Capri, 5/1986 (Springer), pp. 16-29 [2] Schaffert, C., Cooper, T., Bullis, B., Kilian, M., Wilpolt, C., An Introduction to Trellis/Owl, OOPSLA Proceedings, 1986 [3] Decouchant, D., Design of a Distributed Object Manager for the Smalltalk-80 System, OOPSLA '86 Proceedings, ACM 1986 [4 ] Schill, A., Heuser, L., Miihlh~iuser, M., Using the Object Paradigm for Distributed Application Development, GI Informatik-Fachberichte 205, Kiihn (Ed.), Springer, pp. 84-98 [5] Black, A., Hutchinson, N., Jul, E., Levy, H., Carter, L., Distribution and Abstract Types in Emerald, IEEE Trans. on Software Engineering, Jan. 1987 [6] McCnllough, P.L., Transparent Forwarding: First Steps, OOPSLA '87 Proceedings, ACM 1987 [7] Heuser, L., Object Cooperation: Supporting Algorithm Development in DOCASE, Proc. of the 2nd int. Workshop on "Distribution and Objects", Karlsruhe, GY, 1989, pp 116-126 [8] Kienh6fer, J., Riickgekoppelte Baumrechner und Programmierung, Angewandte Informatik, Vieweg, 5/89 [9] Frank, H., Computerizability of Requirements Engineering, Proc. of the 2nd int. Workshop on "Distribution and Objects", Karlsmhe, GY, 1989, pp 8186
327
A SOFTWARE ENGINEERING ENVIRONMENT FOR DISTRIBUTED APPLICATIONS M. Miihlh~iuser1, A. Schill 1, J. Kienh6fer 1, H. Frank2, L. Heuser 2 IUniversity of Karlsruhe, Institute for Telematics, Zirkel 2, D-7500 Karlsruhe, West Germany 2Digital Equipment GmbH, CEC Karlsruhe, Haid-und-Neu-Str. 5, D-7500 Karlsruhe, West Germany With the recent development of powerful workstations integrated in local area networks, the need for distributed applications has increased significantly. This way, formerly autonomous applications of areas like computer integrated manufacturing or office automation can be integrated to cooperating entities. However, the development of these kinds of applications is still not well supported The paper describes an object-oriented software engineering approach for distributed applications. The approach is centered around a wide-spectrum design language used as a common base for a set of workbenches. The associated tools are focusing on problems related to distribution and complexity of applications. Life-cycle spanning development support shall be provided by the environment. Keywords: Computer Aided Software Engineering, Methods and Techniques, Distributed Applications, Object-Oriented Programming, Object Mobility, Object Cooperation, Parallelism, Requirements Engineering.
1.
INTRODUCTION
The ever continuing computerization of our society is presently marked by a growing cooperation and inter-operation of formerly independent and isolated systems, in both hard- and software. As a consequence, the task of computing becomes more and more that of coping with complex distributed systems. In hardware, this trend is speeded up by the rapid deployment of networked workstations and by new communication media which increase communication capacities by orders of magnitudes. In software, a trend to growing integration and cooperation of formerly autonomous applications can be observed in many fields; computer integrated manufacturing, office automation, and information management systems are example domains in which complex distributed software plays a dominant role already today. We call such complex distributed software distributed applications in the remainder, in order to contrast it from operating system level software. We call for appropriate software engineering support - comprising environments, tools, and linguistic aids - for developing distributed applications. The paper describes the project DOCASE - distribution and objects in CASE (computer aided software engineering). It is the intend of DOCASE to help show the way towards environments, tools and languages which are appropriate for distributed programming. In this attempt, we made use of, or had to reflect, other major trends in software engineering:
•
Environments: environment distribution, kernel standardization, and extendibility Due to the fact that programming in the large is more and more carried out in a distributed system with each developer having his own workstation, software engineering environments tend to become themselves distributed. We consider this trend towards environment distribution important, still putting a larger emphasis on application distribution, as described above. The skeleton of software engineering environments - in terms of functions, human interfaces, and data repositories - is currently undergoing a standardization process. Efforts for such standardized environment shells exist in Europe (PCTE, PCTE+) [1] and in the U.S, (CAIS). Extendibility is the attempt to keep an environment open for future extensions (e.g., new tools to come). First approaches, decoupling relevant data definitions and data from individual tools, showed great advances but are still insufficient.
•
Tools: CASEtools and ToolSets. CASEtools support software engineering methods - formerly performed with paper and pencil - on workstations, with a growing level of integration with other tools. The tendency to integrate tools across the software life-cycle leads to ToolSets, where the intend is to provide a 'common look and feel' and easy data sharing among the tools in a set.
M. MDhlh#user et aL / A Software Engineering Environment
328
•
Linguistic aids: object-orientation
and design
support. Object-oriented languages [2,3], with the strong modularity they enforce, proved to help managing complexity, a major problem of distributed applications. The very few existing approaches to distributed object-oriented programming proved that a number of helpful concepts in distributed programming can be easily introduced using the object paradigm (e.g., transparency of the underlying network structure). Design support is provided by so-called wide-spectrum languages coveting the range from high level, incompletely specified early development phases to low level, detailed description of software. The seamless path from early to late phases and the ease of maintenance make this approach very attractive.
HMI-Layer
[DODL-TranslatorI
Functional
ji
Regarding our central goal of distributed application development and the major trends pointed out, we summarize the basic requirements for the DOCASE environment as follows: 1.
Reflect the complexity of distributed applications through design level support and object-oriented linguistic aids.
2.
Provide openness and extendibility
3.
Meet requirements of distributed programming in linguistic aids, in tools, and in the environment.
4.
Provide life-cycle spanning support.
2.
THE DOCASE ARCHITECTURE
NOTE: For the remainder, we refer to the enclosed figure of the DOCASE environment architecture. Shaded parts refer to software parts imported, i.e., not implemented as part of the project. The architecture distinguishes humanmachine-interaction (HMI layer) and data aspects from mainly functional aspects. Parts not described in the remainder (especially in the HMI layer and in the data layer) were left out in the figure.
JRuntirneSystemI
...............................
. . . . . . .G£ . . . .iiiii!iiiii!i. . . . . . . . . . . . .iiiii . . .:!i. . . . . .
DOCASE Kernel Interface
Data Layer
The D O C A S E Architecture 2.1
The semantic center: DOCASE design language - DODL
Object-Orientation: We decided to develop an object-oriented language DODL as the center of distributed application development. Information hiding, uniformity, and inheritance as introduced in the object-oriented approach help coping with distributed application complexity. On the other hand, the uniformity of the object-oriented approach has major deficiencies: tools do not "see" the semantic characteristics of objects (distinguishing, e.g., processes, private and exchanged data, files etc., as with conventional programming). DODL therefore defines a top-level hierarchy of objects known to all tools. In contrast to known object-oriented approaches, we make the differences between a) more stable, "structural" objects, b) more volatile, "moving" objects generated in large quantities, and c) semantic relations between objects visible to tools and developers.
Design Level: DODL also follows the "wide spectrum" paradigm, providing very abstract constructs for a high level description of application stmcture, functional behavior, and communication, which can be further refined in DODL until the implementation level of detail is reached. From there, a transformation into a target (distributed object oriented) language is provided.
Distributed programming: DODL reflects distribution aspects: communication not
M. MShlh#user et al. / A Software Engineering Environment
only occurs implicitly via method calls, but also explicitly via communication relations. In addition, the flow of DODL generated objects (see below) can be explicitly stated. Configuration of objects in a distributed system, including dynamic configuration changes, can be expressed in dedicated configuration sections. Extendibility: A developer can define new object types as subtypes of the DODL top level hierarchy: new predefmed objects, new predefined methods, and language extensions can be defined, and will be reflected in many of the DOCASE standard tools. DODL code is analyzed and precompiled by the DODL translator, translating into an intermediate format. The DODL translator interacts with both the workbenches (see below) and the DODL editor. The latter supports both graphical and alphanumerical views and is one of the principal interaction tools for the user. The open definition of the DODL translator interface allows for extensions (e.g., support for new tools). DOCASE is providing a number of generic design objects applicable through DODL. These objects form a class hierarchy [4] exploiting inheritance. Objects generated from this class hierarchy represent a particular design. They form an arbitrary instance hierarchy describing the overall top-down view of the designed system. The advantage of the explicit top-level hierarchy is that all CASE tools (graphical design aids, runtime visualization tools, etc.) can exploit it. Below, the major classes will be introduced. The DOCASE object is the highest level class. It is an abstract class with different concrete subclasses: the configured objects, the (dynamically) generated objects, and the relation objects. Configured objects are created, deleted and modified by special configuration operations. The distinction of configured (intuitively "visible", more "static") objects and generated (intuitively "shortliving", more "dynamic") objects has been proven to be very close to a software designer's way of thinking. We introduce relation objects in order to represent static and dynamic relations between other objects. The explicit and separate expression of inter-object relations is one of the key issues of DODL. 2.2
The functional center: workbenches
Specific development aspects in DOCASE are handled by DOCASE workbenches. A workbench can be characterized by the following properties: •
Common framework for a collection of tools (cf. ToolSet in chapter 1).
329
•
Orientation towards a common goal related to a specific development aspect.
•
Life-cycle spanning functionality (as far as the development aspect is life-cycle spanning).
•
Uniform, phase independent human-machine-interaction with all tools in the workbench.
•
Integration with DODL representation.
Both the developer and the workbenches are able to reflect their decisions right in DODL syntax, i.e. the DODL representation is providing a common base for all development aspects. Due to the focus of DOCASE on distribution, the following workbenches are currently under development: 2.2.1 Mobility Workbench: Current distributed object-oriented systems only provide basic facilities for object mobility [5,6]. Object migrations have to be stated directly in application code. They are usually focusing on the goal of collocating communicating objects at a common node in order to reduce remote interactions. The direct use of these facilities, however, is associated with a number of problems for the application developer. In large applications, the complexity of determining appropriate object migrations can be significant. From the software engineering point, distribution independent application code is intermixed with distribution dependent mobility instructions. Therefore, we are proposing a higher level, goal oriented approach to control object mobility. It realizes event based decisions concerning object migrations. It is considering a-priori information about expected inter-object communication as well as runtime information including object sizes, current object locations and current object invocations. To represent a-priori information, we introduce a special construct called collocation definition. A collocation definition is used to identify objects to be collocated dynamically. These objects are described by a tree structure built from formal object parameters which are linked by relations. A collocation definition also comprises an initiation event and a termination event controlling the lifetime of its collocations (see below). Relevant events can be method invocations and their return and the creation and deletion of inter-object references. The a-priori information describes the expected future inter-object communication which is caused by a method invocation or which is associated with an inter-object relation. Collocation definitions can be explicitly given by the developer using a special syntax or can be generated by the system by performing call analyses.
330
IV~. M5hlh§user et al. / A Software Engineering Environment
At runtime, a collocation is created as an instance of a collocation definition when its initiation event occurs. Then a distributed algorithm is executed to identify the associated objects, collect theft runtime information and decide about actual object migrations. A logical node to collocate the objects is selected heuristically considering migration costs and mobilityrestrictions. Conflicts between different collocations including the same objects are resolved heuristically, too. Collocations are deleted on occurrence of theft termination event given by the collocation definition. The approach offers different levels of abstraction conceming the problem of mobility control. They are ranging from explicit specification of objects to be collocated up to (limited) automation of migration decisions. A conceptual description tool, a runtime mobility control component and a monitor component realizing our approach have been implemented. They are based on an environment providing an object-oriented emulation of distribution.
port their development. Algorithms are defmed as operations or object cooperations to fulfill a specific task. We distinguish between:
•
Basic algorithms which are provided by objects of the application. They are implemented as operations and are the basic components of the procedural model.
•
Complex algorithms are composed of existing object cooperations and basic algorithms. They define the procedural behavior of sets of objects to perform complex application tasks.
A complex algorithm can be typed and inherit behavior from supertypes. A "create" operation enables the programmer to use several instances of the same algorithm. Like object types in DODL we would like to classify the types of complex algorithms depending on the level of abstraction they provide. The Object Cooperation Workbench will provide a design method and tools which support the development of complex algorithms using the DODL as platform.
2.2.2 Object Cooperation Workbench: The following paragraphs describe the reference model of the Object Cooperation Workbench. The complexity of a distributed object-oriented application could be measured by the number of objects it consists and by the number of threads of control it fires. The first value describes the complexity of the static application architecture, whereas the other one represents the complexity of the dynamic procedural behavior This distinction of software complexity is the basis of the reference model [7]. The procedural model, which is the upper layer of the reference model, provides two views. The operative view figuring the operations of an object has close relationships to the structural model, the lower layer of the reference model. The procedural view presents functional building blocks (tasks) implemented as complex algorithms. In large applications functional building blocks exist which involve operations of many objects. Especially, distributed applications perform complex algorithms due to the distribution of objects. Besides the complexity of the application domain the problem space of reliable execution is taken into consideration. This complex algorithms are representing' real world processes which could not be adapted to any object of the application. In addition, complex algorithms arise a new dimension to the designer's world: Time. Algorithms could stay for a long time within the system. They have to fulfill requirements about their duration and the meantime between service requests and related responds. Therefore, an extension to the structural model is required to treat complex algorithms as independent objects and to sup-
2.2.3 Concurrency Workbench: The concurrency workbench consists of three tools which help the designer using three parallel programruing methods. For achieving reasonable parallelism we combine these programming methods with a special communication structure on processors called backlooped tree. Experiments show that when the potential degree of parallelism is used the speedup grows nearly linearly with the number of processors. The divide-and-conquer approach (d&q) as the first programming method can be parallelized according to the message-passing d&q as described in [8]. Within the tool the designer is able to ftll out a recursive dataflow graph, which shows graphically the d&q algorithm. The layout is then transferred to the DODL language. The second parallelism method is the SIMD approach. It can be seen as a specialization of the d&q approach. It is distinguished from the d&q that only data structures are divided into several pieces. All subdata can now be treated with the same instructions. If the division is carded out with an divisor equivalent to the number of processors in use, the speedup is maximal. In the third programming method the designer uses parallel constructs explicitly. He tells the system which task has to run on which processor and which task communicates with which task. It is possible that messages have to be routed through other processors. This programruing method is supported with a graphical interaction editor, where a dataflow graph can be designed. The mapping from the dataflow graph to the underlying net-
M. MShlh§user et aL / A Software Engineering Environment
331
work is made automatically. According to the number of processors between two communicating tasks (is proportional to log n, n= number of processors in the network), the speedup is nearly equivalent to the number of processors.
•
Implementing all three programming methods with a task-scheduling-mechanism will enable us to generate programs running on parallel processors which communicate over the Optimal Back-Looped Tree. The supporting workbench will be integrated into DOCASE.
During the Requirements Engineering process the workbench requires sets of related requirements as input. Each requirements set describes a specific part of an application. The base of reusable packages is then searched for matching formatted requirements.
2.2.4 Requirements Engineering Workbench: The combination of object-orientation and explicit toplevel structuring introduced in DODL made it feasible to allow for computer assistance in Requirements Engineering [9]. The work steps considered as part of Requirements Engineering hereby are the Requirements Gathering, Requirements Analysis, and Requirements Transformation.
Requirements Gathering is the analysis of the current situation and the identification of the needs for a change. If the decision is made to use computer support to introduce the necessary changes the next step has to be the Requirements Analysis. Here the Requirements Gatherhag is often redone as now the most obvious software and hardware constraints are introduced. The goal of this task is to structure the requirements so that it is possible to analyze the description for missing details. Errors occurring during this step will influence the software development and increase the necessity for cycles during the development process. To gain the first software model out of the Requirements Specification it is necessary to transform the real-world model of the application into a software oriented schema and representation. This step is called Requirements Transformation and forlns the linkage to the Software Engineering process. The goal of the workbench is to support the work steps in Requirements Engineering and to include work steps during the Software Engineering process that are requirements related. The following main support steps are considered: Requirements Engineering - notation for requirements entries - animation for the requirements notation - reusable requirements in the form of software packages + description in the requirements notation - transformation into DODL
Software Engineering identification and isolation of reusable software packages - inclusion into the package base for Requirements Engineering -
If a matching description is found the user can generate an animation to verify the behavioral match to the new application. In the case that the matching process returns several similar matching descriptions, the animation facility is used to verify the best or closest fit for the new application. Applying this process to all requirements and using all available and matching reusables builds a model of the application in the requirements representation plus in a software representation - in this case in DODL. 2.2.5 Importing Workbenches Other development aspects, e.g. project time management, can be handled by importing existing tool sets as external workbenches due to the openness of the kernel interface (see above). Such external workbenches, however, do not necessarily meet all the properties summarized for DOCASE workbenches above. 2.3
The target: runtime environment
DOCASE is not restricted to a single type of mntime environment: several target languages can be envisioned into which DODL will be transformed automatically. Such target languages have to be distributed and objectoriented. Emulated and simulated runtime environments may also be supported. (In fact, up to the point when robust distributed object-oriented languages will be available for the DOCASE project, the iuntime environment for DOCASE will be one with emulated distribution). Command and control access of the workbenches to the environments (e.g. to control and monitor the application execution) is realized through a common command / event interface to be implemented for every target runtime system. The actual transformation is going to be performed by the DODL compiler when an application design has reached a sufficient level of detail. Object class definitions and parts of the executable DODL code can be transformed directly into the code of a distributed object-oriented language. Specific constructs addressing mo-
332
M. MDhll~user et al. / A Software Engineering Environment
bility control (see below) or other higher level support have to be translated into calls to library routines. Appropriate libraries will be provided by the DOCASE kernel. In addition, various kinds of description data given by a DODL design have to be made explicit to the runtime environment. Examples are inter-object relations or application events. This information is extracted by the DODL compiler and is written onto separate files. At runtime, it is loaded and fed into the higher level tools of the DOCASE workbenches. If parts of a DOCASE design are still incomplete or do not provide enough semantic information to generate executable code, they can be annotated by support data from emulation or simulation of the desired behavior Examples are the specification of expected communication delays or of invocation durations. By supporting the transformation step, the well-known gap between design and implementation of an application is filled. This way, the need for re-coding an application in a different implementation language is vanishing. Full support for the generation of very efficient and final code, however, requires intelligent compiler techniques which are currently outside the scope of our project. 2.4
The envelope: kernel interface
The kernel interface defines a general view of DOCASE (including its external workbenches) to standardized environment shells as described in chapter 1. This is realized through the DOCASE kernel interface, consisting of three parts: an interface to the data repository (a realization independent schema defmition with semantic extensions), an interface to the basic functionality (operating system and shell independent system service and shell command definitions), and an interface to the humanmachine-interaction layer (an object library for screen artifacts and input items). Like the command / control interface to runtime environments, the kernel interface has to be implemented for every environment shell to be used with DOCASE. 3.
CONCLUSION
We showed that state of the art software engineering is inappropriate for one of the major challenges in software production of the near future, namely distributed application production. We gave an overview of approaches
in all related fields - linguistic aids, tools, and environments - of software engineering, integrated in the software engineering environment DOCASE and presented short surveys of the current workbenches. At present, the DODL definition is finalized, the ftrst version of the mobility workbench is nearing completion, and the DODL editor and translator are well under way. For the other DOCASE workbenches currently only partial and prototypical realizations exist as their detailed specification is yet in work.
REFERENCES [ 1] Gallo, F., The PCTE initiative: toward a European approach to software engineering, Proc. CRAI workshop on Software Factories & Ada, Capri, 5/1986 (Springer), pp. 16-29 [2] Schaffert, C., Cooper, T., Bullis, B., Kilian, M., Wilpolt, C., An Introduction to Trellis/Owl, OOPSLA Proceedings, 1986 [3] Decouchant, D., Design of a Distributed Object Manager for the Smalltalk-80 System, OOPSLA '86 Proceedings, ACM 1986 [4 ] Schill, A., Heuser, L., Miihlh~iuser, M., Using the Object Paradigm for Distributed Application Development, GI Informatik-Fachberichte 205, Kiihn (Ed.), Springer, pp. 84-98 [5] Black, A., Hutchinson, N., Jul, E., Levy, H., Carter, L., Distribution and Abstract Types in Emerald, IEEE Trans. on Software Engineering, Jan. 1987 [6] McCnllough, P.L., Transparent Forwarding: First Steps, OOPSLA '87 Proceedings, ACM 1987 [7] Heuser, L., Object Cooperation: Supporting Algorithm Development in DOCASE, Proc. of the 2nd int. Workshop on "Distribution and Objects", Karlsruhe, GY, 1989, pp 116-126 [8] Kienh6fer, J., Riickgekoppelte Baumrechner und Programmierung, Angewandte Informatik, Vieweg, 5/89 [9] Frank, H., Computerizability of Requirements Engineering, Proc. of the 2nd int. Workshop on "Distribution and Objects", Karlsmhe, GY, 1989, pp 8186