motorola (PDF)

Document Sample
motorola (PDF) Powered By Docstoc
					         Thinking Adaptively: the Demeter System
                        Cristina Videira Lopes y Karl Lieberherr

                                    College of Computer Science
                                    Northeastern University

                                           June 22, 1994

1 Introduction
Software applications have been growing for the last two decades in terms of size, complex-
ity, diversity and importance, transforming them from one-person/short-term assignments to
several-persons/long-term projects. In this context, the viability of applications is strongly
dependent on the organization of the software and on how quickly changes can be imple-
mented. Researchers have been aware of these problems, and have come up with solutions
such as object-oriented programming and programming language independent interface de ni-
tions (IDLs). Object-oriented programming provides a natural modeling of the world based on
objects and relations between them. Objects are grouped into sets of objects with similar func-
tionality, called classes. Object-oriented programming also allows a particular kind of reuse by
subclassing. Interface de nition languages address other problems, such as entity speci cation
and collaboration between software components from di erent vendors.
Although software technology has come a long way, the particular issue of change is still
a ecting the productivity. In fact, object-oriented programming not only does not provide
a systematic approach to the problem but also introduces new problems in understanding
programs as a whole, due to the proliferation of many small member functions WMH93], typical
to objects and encouraged by style guidelines for good programming LHR88, LH89]. Another
problem with object-oriented languages is that functions are attached to classes, introducing an
implicit commitment to maintain each function's code dependencies on its own class and on the
classes to which the code refers. With class structures changing frequently, this maintenance
represents a substantial e ort.
     Supported in part by the National Science Foundation under grant numbers CCR-9102578 (Software Engi-
neering) and CDA-9015692 (Research Instrumentation), IBM, Ciba Geigy, and Citibank.
   y Supported by the Portuguese Foundation for Research, Science and Technology (JNICT).

Adaptive programming Lie94, LX93] is a generalization of object-oriented programming, which
allows to understand and develop the code focusing on its global functionality. It stresses
the importance of good programming style and considers change as a real issue during the
application life. The Demeter system HSX91, SLHS94] provides adaptive software development
through graphical descriptions of class structures and a high level language that de nes behavior
in terms of groups of classes. In addition, it supports the de nition of application-speci c syntax
to describe objects by sentences. The Demeter tools generate object-oriented code, i.e., classes
and their member functions, from the high level de nitions of class structures and functions.

2 Class Dictionary Graphs
In the Demeter system class structures are modeled by graphs, called class dictionary graphs
(CDGs), in which vertices represent classes and edges represent relations. CDGs contain three
kinds of vertices: construction vertices, drawn as rectangles, represent instantiable (non ab-
stract) classes alternation vertices, drawn as hexagons, represent abstract classes repetition
vertices, drawn as a composition of a hexagon and a rectangle, represent a container class of
some other class (a list). There is a set of special construction vertices, called terminals and
drawn with a T inside the rectangle, which represent Demeter pre-de ned classes. CDGs also
contain three kinds of edges: construction edges, drawn as labeled single lines with an arrow,
represent the knows-of relation alternation edges, drawn as double lines with an arrow, must
start at an alternation vertex and represent the can-be relation repetition edges, drawn as single
lines with an arrow outgoing from construction vertices, represent the one-to-many knowledge
An example of a CDG is shown in gure 1. It models a very simple approach to a banking
class structure, by which a bank contains several accounts that are either checking or savings.
Each account contains an identi er, a balance and information about the costumer to which it

3 Propagation Patterns
In the Demeter system, functionality is expressed in terms of propagation patterns. A
propagation pattern consists of an operation signature (name and parameters), a set of graph
traversal directives referring only to strategic classes and a set of code fragments written between
(@ and @) which contain the important code for the functionality.



                                    acc_id        balance
    Bank             Account_list                                 Costumer             DemString
             acc_l                                        owner                           T

                                Savings               Checkings

                  Figure 1: Class dictionary graph for a banking application.
A possible functionality of the banking application would be to print all the checking accounts,
that is, their identi ers, balance, names and addresses of the owners. Figure 2 shows a propaga-
tion pattern that implements this functionality. Its only assumption is that Bank objects know
about Checking account objects, following some path in the graph when the traversal reaches a
Checking account object, the wrapper code is executed in this case, it calls a function, g print,
de ned for all classes by the Demeter library, which prints all parts of an object.

                              *operation* void print_checkings()
                                  *from* Bank *to* Checking
                                *wrapper* Checking
                                  (@ this->g_print() @)

               Figure 2: Propagation pattern for printing all checking accounts.

4 Adaptiveness
Adaptiveness comes from the fact that functionality is de ned with minimal assumptions con-
cerning the class structure. In fact, if the banking class structure is now modeled by the graph
shown in gure 3, no changes are necessary in the de nition of print checkings: the high level
description of the function applies also to this other graph, which models a bank by containing
a list of branches, each one containing a list of accounts.
    Bank             Branch_list



                                      acc_id         balance
                     Account_list                                    Costumer             DemString
                                                             owner                           T

                                   Savings               Checkings

            Figure 3: Another class dictionary graph for the banking application.

5 Availability and Future Work
The Demeter system is being developed at Northeastern University, since 1985. The system
consists of an object-oriented methodology supported by a set of tools, such as graphical CDGs
editors, a class structure checker, a propagation tool and code generators. Although several
object-oriented languages have been tested, the most used implementation is Demeter/C++.
The concept of adaptive software is young and there are many opportunities to develop it
further. One of the most promising elds is how to extend adaptive concepts to distributed
applications. Abstracting distribution from the de nition of objects and/or functions will be
a powerful mechanism to deal with the problems inherent to these applications. The basis
for this line of research has already been started, by generating CORBA IDL OMG91] as
an intermediary language for class de nitions. Another issue, related with distribution, but
not exclusively, is partitioning of adaptive programs into groups of collaborating propagation
patterns and groups of collaborating CDGs.
The commercial version of Demeter/C++ is managed by Demeter International, Inc. For
further information, contact Demeter International, Inc., 56 Bennet Road, Marblehead, MA
01945 USA, (617) 631-9139 or send e-mail to

HSX91] W. Hursch, L. Seiter, and C. Xiao. In any CASE: Demeter. American Programmer,
       4(10):46{56, October 1991.
LH89]    Karl Lieberherr and Ian Holland. Assuring good style for object-oriented programs.
         IEEE Software, 6(5):38{48, September 1989.
LHR88] Karl J. Lieberherr, Ian Holland, and Arthur J. Riel. Object-oriented programming:
       An objective sense of style. Number 11, pages 323{334, San Diego, CA., September
       1988. A short version of this paper appears in IEEE Computer, June 88, Open
       Channel section, pages 78-79.
Lie94]   Karl Lieberherr. The Art of Growing Adaptive Object-Oriented Software. PWS
         Publishing Company, February 1994. To be published.
LX93]    Karl Lieberherr and Cun Xiao. Object-oriented software evolution. IEEE Transac-
         tions on Software Engineering, 19(4):313{343, April 1993.
OMG91] OMG. The Common Object Request Broker: architecture and speci cation, Decem-
       ber 1991.
SLHS94] Ignacio Silva-Lepe, Walter Hursch, and Greg Sullivan. A Demeter/C++ Report.
        C++ Report, SIGS Publication, February 1994. To be published.
WMH93] Norman Wilde, Paul Matthews, and Ross Huitt. Maintaining object-oriented soft-
       ware. IEEE Software, pages 75{80, January 1993.


Shared By:
fanzhongqing fanzhongqing http://