Below is a list of limitations from the Programming Technology Lab in Brussels. Please send more, I will compile a list and then we will look for solutions which some of the participants might have. The Programming Technology Lab group points out that there are many definitions for adaptability. I fully agree and I would like to refer to my definition which is in: Title: Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns Author: Karl Lieberherr Publisher: PWS Publishing Company ISBN: 0-534-94602-X Year: 1996 On page 77, which is on the WWW in the sample chapters, you find one way of defining adaptiveness. For more information, including the foreword by Gregor Kiczales and John Lamping from Xerox PARC plus some sample chapters, see URL: http://www.ccs.neu.edu/research/demeter/ -- Karl Lieberherr PS. The book is available in your bookstore or by contacting order@pws.com. ======================================== From clucas@vnet3.vub.ac.be Mon Sep 18 09:01:16 1995 To: adaptable-participants@ccs.neu.edu Subject: OOPSLA WORKSHOP: Inhibitors to adaptibility In your mail about the workshop you asked all participants to mail you a short list of limitations or inhibitors to adaptibility. Here is our list. * One of the main problems in adaptive software is to find a good WAY TO DESCRIBE THE CONSTRAINTS to which adaptations should comply. The art is in finding the right balance between constraints that are easily understood and expressed and constraints that capture enough of the semantics of possible adaptions. * It is clear from the position papers that there is not just one definition for adaptability. Furthermore, it probably would be against the nature of the subject to strive for one. Therefore, POSSIBLE ADAPTIBILITY MECHANISMS SHOULD NOT BE TOO RIGID. * A number off problems occur because of the different kinds of people that work on one system; e.g. the framework developer, the framework user, the end user. An adaptive PROGRAMMING ENVIRONMENT needs to be supportive to all of these KINDS OF USERS. Regards, Patrick Steyaert, Carine Lucas, Koen De Hondt Free University of Brussels ************************************************************ * Carine Lucas * * Programming Technology Lab * * Vrije Universiteit Brussel * * Pleinlaan 2 * * B-1050 Brussels tel. (32) 2-629.34.92 * * BELGIUM fax. (32) 2-629.34.95 * * http://progwww.vub.ac.be/prog/persons/carine/clucas.html * ************************************************************ Below we get a list of limitations from Roger Burkhart. It appears to be better at this point to collect limitations from anyone who wishes to contribute and not just from the 4 presenters we selected initially. We adapt to the situation. :-) Roger Burkhart writes: ======================== > Lack of dynamic structure within software implementation to respond to varying needs, and the need for all this structure to be manually generated. > Insufficient abstraction in design languages to express functionality of software independent of its internal structure. > Need for explicit mechanisms for users of software to communicate their particular usage (e.g., customizations and restrictions) of generalized facilities and interfaces. > Need for software to present multiple views to its various users under separate interfaces designed for each use, and yet still maintain coordinated state and interaction. > Lack of generic, machine-processable representations of both designs and implementations by which to generate and process evolving structures. These are just off the top of my head, by no means trying to be complete. But I'll be looking forward to hearing and talking about any and all the issues at OOPSLA. See you there! ====================== Below is an additional limitation identified by Paul Clements from the Software Engineering Institute. I would like to add that for certain kinds of adaptive abilities, the cost may be negative! This means that by making our programs more flexible and more general, they become simpler and easier to develop. This is an instance of Polya's inventor paradox which he describes in his book: How to Solve it. For more, see page 80 of my book on the WWW (ftp://ftp.ccs.neu.edu/pub/people/lieber/selected-book-chapters.ps) -- Karl ========================= From pclement@SEI.CMU.EDU Tue Sep 19 11:56:36 1995 To: lieber@ccs.neu.edu Subject: Re: limitations to adaptability Cc: pclement@SEI.CMU.EDU Karl, I think you have an admirable list of inhibitors from which to work. My list mirrors those that have already been submitted, with one exception: I believe that an inhibitor is our inability to assign cost/benefit information to a specific adaptive ability. This is, from the software developer's point of view, another way of saying (complaining) that "the user cannot tell us what is required". However, I believe that we could help the user tell us set his requirements if we could communicate to him in terms of the cost of providing a particular adaptive capablity, which we cannot currently do. It would also help is we could help him estimate the benefit of the capability, in his terms. Because this involves things like economic models in which few of us are skilled, it doesn't receive much attention. There are a few folks trying to bridge the gap, creating business models for reuse. Jim Withey of the SEI personifies a good example of this work. Regards, pc ====================== From: axb@defender.dcrl.nd.edu To: adaptable-participants@ccs.neu.edu Subject: A solution from work in the OS area Date: Tue, 10 Oct 1995 15:52:08 -0500 My work over the last few years has focussed on adding extensibility to commercial OSs - hence, I have a strong bias towards issues of adaptability as they apply to legacy systems. The main inhibitors to extending existing OSs are relatively obvious - large code size, non-modular code, severe backward compatibility restrictions, debugging complexity, performance constraints and so on. As I mention in my position paper, our experience and those of others point to certain steps that may be taken towards evolving existing OSs. These include modularization, identifying the degree of adaptability actually required, integrating some kind of a programming infra structure into the OS and putting in checks to ensure the liveness and integrity of the OS after it has been extended. Based on this short synopsis of my position, I and other researchers in this area have certainly arrived at one possible approach to solving some of the problems : In order to make legacy systems extensible (based on work done on OSs) and adaptable, there is a clear need to come up with a fundamental enabling mechanism(s). This mechanism(s) is primarily a scaffolding that bridges the gap between runtime environment provided by the legacy system and the runtime requirements of the programming infrastructure that provides adaptability. In our area of work, we have observed that these enabling mechanisms typically provide enforced modularity and some basic support for building adaptability. For example, SPIN (OS effort at U. Washington) uses Spindles and Modula-3 for kernel-loadable user modules. Modula-3 enforces protection and Spindles ensure that type-safe user-level code can be downloaded into the kernel. Similiarly, our effort at University of Notre Dame uses the notion of Protected Shared LIbraries (PSLs) and Shared Address Libraries(SALs), where PSLs enforce modularity above and within the kernel and SALs facilitate the implementation of "scope management" of changes made to subsystems. Typically, some kind of a programming infrastructure that depends upon the enabling mechanism actually provides the required support for adaptability. In our case, we have ended up using a set of frameworks that provide the basic meta-object hierarchies required by various OS subsystems. The choice of the enabling mechanism not only depends upon the programming infrastructure that is to be used, but also the extent to which the legacy system code can actually be modified. Our experience suggests that building such scaffolding is critical in making the problem more manageable. - ----------------------------------------------------------------------------- Arindam (AB) Banerji (219)-631-5273 (Voice) 384 FitzPatrick Hall (219)-631-5772 (Voice) Dept. of Computer Science and Engineering (219)-273-0862 (Voice) University of Notre Dame (219)-631-9260 (FAX) Notre Dame, IN 46556 axb@cse.nd.edu (E-mail) HomePage:http://www.nd.edu/Departments/EN/CSE/DCRLab/HomePages/axb - -----------------------------------------------------------------------------