Design and Implementation of Simple Object Description ... - CiteSeerX

3 downloads 33665 Views 161KB Size Report
network application development time has been increased. To enhance our productivity ... design, development and maintenance has to be taken into account.
Design and Implementation of Simple Object Description Language Marjan Mernik, Uros Novak, Enis Avdicausevic, Mitja Lenic, Viljem Zumer University of Maribor Faculty of Electrical Engineering and Computer Science Smetanova 17, 2000 Maribor, Slovenia (+386 2) 220 7455

{marjan.mernik, uros.novak, enis.avdicausevic, mitja.lenic, zumer}@uni-mb.si

Keywords Domain-specific languages, attribute grammars, incremental language design.

ABSTRACT In the paper a design and implementation of Simple Object Description Language SODL for automatic interface creation are presented. First, problem domain – developing network applications and reasons for developing new domain-specific language are described. Since the cross network method calls slow down performance of our applications the solution was Tier to Tier Object Transport (TTOT). However, with this approach the network application development time has been increased. To enhance our productivity a new domain-specific SODL language has been designed. Syntax and semantics of SODL language are formally defined in an incremental way by special kind of attribute grammars that allows extensions and modifications in an easy way. From formal specifications SODL compiler is automatically generated using compiler/interpreter generator tool LISA. Finally, the benefits of our approach have been discussed.

1. INTRODUCTION The primary function of programming languages has always been to make the programmer more effective. It is well known that programming languages can greatly increase programmer productivity by allowing the programmer to write a high-scalable, generic, readable and maintainable code. In this regard, a domainspecific language, which is a programming language for solving problems in a particular domain and provides built-in abstractions and notations for that domain, is by no means an exception. Domain-specific languages [15, 14, 4] are usually small, more declarative than imperative, and more attractive than generalpurpose languages for a variety of applications because of easier Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC 2001, Las Vegas, NV © 2001 ACM 1-58113-324-3/01/02...$5.00

programming, systematic reuse and easier verification. However, the benefits of domain-specific languages are not for free. The cost of domain-specific language design, development and maintenance has to be taken into account. Without an appropriate methodology and tools this cost can be higher than savings obtained by the later use of domain-specific language. Advantages of the formal definitions of general-purpose languages should be exploited, taking into consideration the special nature of domainspecific languages. An appropriate methodology that considers frequent changes of domain-specific languages is needed. To be productive, the development of these languages must be based on high-level automated tools with support for both: the design and implementation. In the paper a design and implementation of a new domainspecific language, Simple Object Description Language (SODL), for automatic interface creation is described. The SODL language is implemented by novel approach, taking into account that domain-specific languages are modified and extended much more frequently than general-purpose languages. The organization of the paper is as follows. In section 2 our problem domain - developing network applications and reasons for developing new domain-specific language are described. Design and implementation of SODL language is described in sections 3 and 4. Followed by related work in section 5. Finally, our experience with design, implementation and usage of SODL language are described in section 6.

2. PROBLEM DOMAIN Recently, we have been involved in development of several network applications accessible through web browsers and desktop applications. Since the Windows NT Server was selected as the target server platform for our projects, the Windows Distributed interNet Application (DNA) model is used. The decision to use Windows DNA as a base system architecture model allowed us to gradually develop and extend certain patterns in all levels of system development: analysis, design and implementation. We have spent a great deal of time to ensure the performance and scalability of our applications. One key to achieve good performance and scalability is efficient data movement between the tiers. Practically every bit of data in the system is encapsulated inside of entity objects. Other objects in the system access and manipulate data through method calls on entity objects. An example of a common scenario is shown in

figure 1. User interface object A invokes a method on a business object B. Invoked method creates new entity object C, performs some application specific initialization of object C and passes a reference to the object C as the result of a method call. Object A then invokes several different methods on object C to display or manipulate the data. Finally, object A invokes another method on object B and passes a reference to object C as a parameter. This method stores a new state of object C in the persistent storage (database). Note that objects A and C are located on different machines connected through network. Because of that, each time object A invokes a method on object C the call is propagated through network connection by proxy/stub layer. The total number of cross network calls performed in this scenario is 2+n (n is the number of method invocations of object A on object C). This cross network method calls have at least two undesired implications: They are slow. A cross network call can take many hundreds • or thousands of milliseconds to complete. •

Ä

4

5

6

=

7

>

?

8

5

9

Suggest Documents