Bruce Anderson

An iterative-design model for reusable object-oriented software

We present an iterative-design approach for reusable object-oriented software that augments existing design methods by incorporating iteration into the design methodology and focuses on the set of problems within the domain, encouraging reuse of existing design information. The model has five separate stages which are described, before an example design is outlined using the model with sample code constructs in C++. Our results have shown a high degree of code reuse when using the model, directly attributable to two distinct design stages. An analysis of these results is also presented.

Programming in the home of the future

For computers to be truly useful in the home of the future, they should be programmable by their users. The traditional idea of a program must be abandoned in favour of that of an environment of objects; programming becomes the act of augmenting this environment, and all interaction consists of evaluating expressions in it. Developments in language design and software engineering indicate how this very uniform interface might be possible, though this style of use imposes some difficult requirements. In the right such environment simple programming can yield useful results and lead to greater understanding both of the programming process and of the problem being approached. Such a powerful system could be used in three main areas: the local manipulation of data, including games and simulations; device control, which can be sophisticated and energy-conserving; and to communicate with other systems. This last possibility leads us to discuss several uses including mailing, teleconferencing, and access to databases of various kinds. Some social effects of the widespread availability of computer power are indicated.

Software architecture: the next step for object technology (panel)

Architectures are the structuring paradigms, styles and patterns that make up our software systems. They are important in many ways: they allow us to talk usefully about systems without talking about their detail; a knowledge of them gives us design choices; attention to this level can make systems and families of systems have the non-functional properties we want, especially changeability. Each panelist will address the following issues: l What is architecture? l What is the value you have had so far from this concept? l What is the next step for you? l What is the next step for the community?

Encoded pointers — an interesting data-structure for modern sil's

ions see [4] for an excellent discussion of this and related topics. Briefly, however, we require: type RING: corresponding to the RRB, operiltion INIT: to initialise the RRB structures, operations GOL, GUR, INSERT, REMOVE: as in the implementations, operations CONT, SETCONT: to obtain/assign to the current element of the ring. The operations not imp1emente.J above can be coded as shown in Fig. 2. Note that we require objects of type RING to be available to the user, but to forbid access to components of that type. 5. Implementing the abstraction Several requirements are imposed by the representation in quesiion: (1) a type of object upin which to perform the XOR operation. Some larguages have a WORD datatype and allow logical (i.e. bit-p~lrallel) operations upon them, whereas oth:rs insist on an array of ‘bits and the corresponding serial operation; (2) the ability to fin{:1 out how long a pointer is, in order to choose the correct length of word or bitarray; (3) permission either to view pointers as words/ arrays (and vice-versa), or function to produce one representation from the other. Ada does allow us to implement this scheme in a rnac~liile-independent way. The ACCESS._SIZE attribute of the REB type gives us the length of an address in bits. We can then use this to declare the X component of REB”s as a packed array of l-bit objects, and we can define an XOR function on these objects. The library module UNSAFE_PROG~MMING contains a generic function UNSAFE-CONVERSION which we can instantiate to transfer between the pointer (known as access type) and bitarray representations, The code is outlined in Fig. 3; C~\m&l ,,nint.J fh”, rrr:nn I---Volume lQ, number 2 INFORMATION PROCESSING LETTERS 18 March 1980 type BIT is new BOOLEAN; for BIT use 1; type REB; BMAX: constant INTEGER := REB’ACCESS-SIZE 1; type PWORD is array (0.. BMAX) of BIT; for PWORD using packing; type REB is access record E: VAL; X: PWORD (others =+ FALSE); end record; type RRB is record L, R: REB : = null; end record; **. restricted(XRING, UNSAFE_PROGRAMMING) function PTOPWORP is UNSAFE_PROGRAdMING, UNSAFE_CONVERSION (REB, PWORD); Fig. 3. Partial Ada code for ring abstraction. (a) is the pointer size determinable before the things it points to are fully defined? The defmition of the ADDRESS attribute implies that all pointers are the same length, so this should work. However, on modern machines with large address-spaces and useful addressing-modes one mig’nt wei! want to use short (based) pointers, but Ada does not allow this to be requested, though nothing prevents the compiler from doing it ; (b) will the compiler realise that no computing is needed to turn bit-arrays into pointers, and vice-versa, since we are using the function merely to satisfy typechecking; (c) the iterative XOR is very slow. In practice it would be more satisfactory to take the traditional escape route, turning pointers intO ,ntegers and dropping into machine-code to do the XOR. In C the cast construction ‘(UNSIGNED) x’ gives us X viewed as an UYSIGNED integer, but the definition states explicitly that no computation is done. Similarly C has unions, which are basically variant records with no dkcriminant field, so that we can view a component as a pointer or as a bit-pattern. C does have explicit bitwise operations on unsigned integers, includm!; XOR, but there is no way to obtain the length of’ pointer from the environment, so complete machine-independence cannot be achieved. 6. Discussion These newer languages don’t help greatly in making the implementation a safe one internally; in particular the constraints given above that we must XOR only certain related values, and that we must maintain pairs of pointers to adjacent blocks, cannot usefully be built into further lower-Ievel abstractions. Secondly, the more powerful the language the more complex the implementation becomes, both for the implementer and for the compiler. Thus BCPL has a very simple virtual machine, with simple but powerful operations on it. It is useful for systems programming because it matches current hardware closely enough; machinecode is rarely needed, Ada, on the other hand, presents a complex virtual machine. The more complex this becomes, the harder it is for the programmer to be given control over the mapping of these constructs onto the hardware. Despite the facilities provided for that, which will obviously be useful in many cases, we seem to retain in the case in question a need to exit into machine-code to provide a reasonable implementation of a relative straightforward, though very machine-oriented, concept. While this escape-hatch should no doubt be available, it seems a pity that it should be needed in Ada for this example when the more primitative BCPL manages well without it. Of course Ada solves some problems that BCPL does not even address, and the languages cannot be compared in every dimension. C’s extensive (but often unchecked) type structure places it in between these two languages. Although we set out to see whether this useful implementation trick could be used in a high-level ianguage, our aim was purely exploratory, so that a negative result need not be a pessimistic one. Despite its neatness, the representation has many disadvantages, apart from its obvious fragility: (1) it assumes that pointers are conventional, or, rather, that each REB is represented by a unique (and unchanging) bit-pattern. It fails if pointers are relative (or, more realistically. if those in REB’s are relative and those in RRB’s are absohrte), (2) garbage-collection is made complex since the garbage-collector would have to know about the ring type and its representation. Ada’s garbage-collector Could fail; (3 j multiple references to the ring must be handled