Open Hypermedia Systems Working Group

A framework browser scenario

Document Status
Submitted to the 3rd Workshop on Open Hypermedia Systems
Online available from following page(s) [http://iamwww.unibe.ch/~demeyer/ |http://www.cs.auc.dk/~kock/OHS-HT97/]



• A Framework Browser Scenario
• Scene 1: User Interface Prototype
• Scene 2: Analysis and Design
• Scene 3: Implementation
• Scene 4: Reuse Library

Last revision: 31.01.97

Introductary Remarks

This document is minor rewrite of a chapter of Serge Demeyer's Ph.D. dissertation [Demeyer'96]. It describes a hypothetical "Framework Browser" in the form of a scenario describing the ideal framework programming environment.

One thing to keep in mind while reading this document, is that this scenario relies heaviliy on the list of issues in the "Open Hypermedia requirement List". For the sake of completeness, we included this requirement list below.
An open hypermedia system is a hypermedia system, where the term open implies the possibility of importing new objects into a system. A truly open hypermedia system should be open with regard to:

The Zypher experiment started from the assumption that an Open Hypermedia System forms an ideal technological cornerstone for so-called "framework browsers". To illustrate the scope of open hypermedia we envision, we pick up the idea of an open hypermedia usage scenario. The structure of our scenario comes from the sample published on the world-wide web at http://www.csdl.tamu.edu/ohs/ although we removed some subtitles we found less important and added one title "Our Results" explaining how far the Zypher experiment succeeded in achieving the goals of the scene.

Indeed, the scenario describes the vision that has been driving the design of the Zypher open hypermedia system and that has been partially realised in the prototypes we implemented. Nevertheless, the full completion of this vision has yet to be realised.

The scenario draws upon our experiences developing a Group Decision Support System (GDSS) [Kenis'95]. GDSS research is part of the larger Computer Supported Co-operative Work (CSCW) aiming to support the negotiation process in large groups and to improve the quality of group decisions. The emphasis of this research is on finding suitable communication structures that ameliorate the knowledge transfer between the participants, this way ensuring that more alternatives are considered with more wisdom. A computer may support diverse aspects of such a structured communication process, such as

• the identification of potential conflicts and possible compromises;
• the classification of different ideas, alternatives and opinions within the group;
• the shift from one decision making phase to another (support the 'chair' function);
• the publication of intermediate reports and final decisions (the 'secretary' function).

The scenario itself describes a framework browser as an integrated set of tools that supports an interdisciplinary team in the development of an object-oriented framework. This is another kind of engineering process than the Boeing counterpart presented in [Malcolm,Poltrock,Shuler'91]. We do not claim that this scenario represents the best approach to object-oriented software engineering, nor do we state that the scenario covers all aspects of the framework development process that should be supported by an imaginary framework browser. However, we are confident that the scenario represents a valuable approach towards software engineering and we use citations from [Goldberg,Rubin'95] to sustain our viewpoint.

The reader should be aware that object-oriented frameworks play several roles in this scenario. First, frameworks are the application domain for which we describe an imaginary open hypermedia system. In this sense, the term "framework" denotes all possible frameworks that a group of software engineers might conceive and it is represented by the GDSS framework in this scenario. Second, the scenario is about an integrated set of tools that support a framework development process. The integration is accomplished by means of an imaginary open hypermedia system. In this sense, the term "framework (browser)" stands for tools and is represented by an imaginary framework browser in this scenario. Finally, the scenario illustrates the contributions of the Zypher experiments, which is a concrete incarnation of the above "framework browser" implemented using framework and open hypermedia technology. In this sense, the term "framework" denotes one particular framework providing a reusable design for the domain of open hypermedia frameworks and is named Zypher.

Especially when giving examples and discussing our experiments, it is hard to distinguish between those three roles, because in our experiments all roles are played by one and the same Zypher framework. Note that the Zypher framework has been implemented in the VisualWorks/Smalltalk environment and that the Zypher framework browser incorporates most of the programming tools that come with this environment, such as the system browser, class browser and method list browser. We refer to [Goldberg'84] for more information about these code browsers.

Scene 1: User Interface Prototype

Dirk is a sociologist and has been involved as a consultant in several projects supporting decision making in policy problems. Dirk applies a methodology based on the Delphi method comprising three cycles of paper questionnaires that are distributed among the group members by surface mail. Between each cycle, Dirk analyses the answers, rewrites the questionnaire and redistributes them among the group members. This process takes about a year to produce the final report and Dirk would like to speed it up using computers. To illustrate his vision, Dirk uses HyperCard as a user interface prototyping tool. He authors cards for all the screens he believes are necessary in such a GDSS and links them together to create the effect of a working system.

Goal(s) of this Scene

"Make the end user an insider. Successful teams enrol the end user as an insider, an active member of the product team."([Goldberg,Rubin'95], p.294)

This scene stresses the importance of end user participation, already in the very early stages of software design. The scene shows that a framework development environment should support end users to prototype the user interface and control flow of their system. HyperCard represents the level of end user programming required in such an prototyping environment.

Character(s)

Dirk is the only character in this scene, playing the role of a requirements provider, aggressive tester and enthusiastic supporter ([Goldberg,Rubin'95], p.305). Dirk is a heavy user of all kinds of desktop publishing programs and is able to use such programs to express his ideas. He claims he does not know anything about writing programs, but he has experience with scripting languages and macro facilities that come with the desktop publishing software.

Framework Browser Requirements

To achieve true commitment, end users should play an active role and be able to build parts of the final program themselves. As end users typically do not have the technical expertise to program in full-fledged object-oriented software development environments, a componentware programming environment (like HyperCard) should be integrated with the framework browser. However, to achieve maximum effect, the components offered in the end user environment should correspond with concepts in the application domain. In our scenario, the prototyping environment should include components representing questions, answers and participants besides the generic ones like field, button, label, icon that come along with traditional componentware.

A framework browser should include a componentware programming environment with components tailored towards the target application domain ([OHS-REQ 4]: Data Models).

Our Results

The Zypher experiments do not support the above requirement. However, we were actively engaged in the ApplFLab project, investigating how one could make user interface builders incrementally refinable ([SteyaertEtAl'94], [SteyaertEtAl'96]). This research starts from the assumption that user interface builders are essential tools for the development of modern applications, and argue that the state of the art of the field lacks a way of incorporating new user interface components. The ApplFLab environment can extend its set of user interface components using a special purpose meta-level interface. We plan to combine the ApplFLab environment with the Zypher framework browser in the future.

Scene 2: Analysis and Design

Having finished the GDSS prototype, Dirk starts to look for a group of people that can turn it into a working software system. He pays a visit to Patrick, a member of the computer science department of his university. Patrick happens to have a great deal of experience with object-oriented frameworks and he convinces Dirk to build a GDSS framework. Dirk fancies this idea, because he wants to try the future GDSS in both synchronous-proximate (i.e. all participants are working in the same room at the same time) and asynchronous-distributed (i.e. the participants are connected by a WAN-network and participate at different moments in time) settings and Patrick promises that he will be able to do both.

Patrick is well aware of potential pitfalls when building frameworks, certainly for a domain where he has no experience with. He decides that a "design by wandering around" method is probably the best way to cope with the uncertainties and tries a prototyping approach. To kick of, he starts to browse through the documentation Dirk provided, meets a few times to discuss GDSS ideas and gradually builds up an understanding of what Dirk had in his mind when building the user interface prototype. Patrick finally writes a set of analysis and design documents using his favourite tools (i.e. the Microsoft Word editor and a public domain OMT editor). Patrick uses an open hypermedia system to create numerous hypermedia links representing relationships between the OMT-diagrams and the analysis and design documents.

Goal(s) of this Scene

"Tools. [...] Much of the effort involved in analysis and design involves handling information with complex interdependencies that have to be created and maintained over long time periods. Tools must be available to handle the information management aspect of a (analysis and design) method."( [Goldberg,Rubin'95], p.346)

This scene illustrates that framework development is more than writing an object-oriented program and that a framework browser should support other related tasks as well. Moreover the scene emphasises that software engineers have their working habits and their favourite specialised tools, so that a framework browser must delegate specialised tasks to third party applications.

Character(s)

Patrick enters the scenario. Patrick is the framework designer ([Goldberg,Rubin'95], p.497), the person who determines the architecture for a generic set of parts that can be used to form GDSS applications. In this scene, Patrick designs an initial set of concrete parts to illustrate how the generic parts fit together to form a particular GDSS application.

Framework Browser Requirements

To support the wide range of tasks involved in framework development, the framework browser must be able to integrate any other application. However, the two example applications are quite different with respect to ease of integration. Microsoft Word is an example of a software package that incorporates interoperability standards (i.e. DDE and OLE) and is highly tailorable (i.e. the VisualBasic scripting language) and thus well suited for integration with the framework browser. The public domain OMT editor stands for all other applications lacking such facilities. With the growing support of operating systems, one can expect that more and more applications will adhere to interoperability standards, yet legacy applications will always be around. Techniques to deal with such legacy applications (i.e. like the "universal viewer" [Davis,Knight,Hall'94]) are essential.

A framework browser should be able to integrate any other application, irrespective of the degree of tailorability of such client application ([OHS-REQ 3]: Applications).

Our Results

We have integrated Microsoft Word as a third party document viewer. We used the macro facilities in Microsoft Word to accommodate for the necessary glue and implemented the inter application communication with DDE (Dynamic Document Exchange) under Windows.

The object-oriented implementation of the Zypher framework, makes it fairly easy to reuse the solution to communicate with other applications supporting DDE. Other interoperability standards (i.e. OLE, OpenDoc) could be incorporated if we want to.

However, the glue code in Microsoft Word is tedious to write, large in volume and hard to maintain. There is a definite need for some kind of reuse mechanism to support the incorporation of external application and this need is even stronger as far as communication with legacy applications concerns. We did not experiment with legacy applications due to a lack of resources. Standardisation efforts, and especially the idea of a dual protocol shim like described in [Davis,Lewis,Rizk'96], may answer the need for reusability.

Scene 3: Implementation

Patrick starts implementing a series of prototypes. As his knowledge of the GDSS domain grows, he sees that some of the assumptions in the analysis and design documents are incorrect and that others or missing. As is encouraged in incremental software development, he modifies the analysis and design to reflect his new insights.

To convince Dirk of the progress of the project, Patrick asks Koen to join the team and to develop a really attractive user interface based on the HyperCard prototype. The two of them form a real team now, working on the same artefact and need to synchronise their efforts. Patrick and Koen encounter two types of synchronisation problems.

The first problem is the maintenance of the relationships between evolving analysis, design and implementation. For instance, Patrick carefully designed that part of the GDSS framework that exchanges messages between participants, as this part must vary when building a GDSS-system for a synchronous-proximate or an asynchronous-distributed setting. Patrick included a link from the section in the design document to the places in the code of his prototype that implements this design. However, Koen has code in his prototype that implements the same functionality and Patrick wants the target of his link to include Koen's code as well. In fact, Patrick wants his link to include all current and future code that implements his design; he needs some kind of "smart" links that establish the navigation relationships dynamically based on specific knowledge about the framework architecture.

The second problem has to do with simultaneous access to shared data and what is called "tele-presence". Sometimes Patrick is editing the analysis and design documentation while Koen is reading it, so Koen and Patrick need to be aware that they are simultaneously working with the same document. The viewers on Patrick's and Koen's machines must show the document in a special colour to illustrate they work in a simultaneous access mode, and each time Patrick saves the document Koen must see the latest version. Of course, this schema must work with all applications used to view and edit parts of the framework.

Goal(s) of this Scene

"Framework Goal. Set up a development environment for all team members that enables the team to create, maintain and deliver applications." ([Goldberg,Rubin'95] , p.376)

This scene portrays that incremental development and teamwork implies facilities for consistency maintenance and integrity control. Professional software development environments may include such facilities, but when a framework browser incorporates third party applications it cannot rely on these facilities.

Character(s)

Koen comes on stage now, playing the role of an implementor in an application production team ([Goldberg,Rubin'95], p.282), specialised in user interface design. Koen stands for other characters with other specialisation's (i.e. databases, networks, statistics) as well. The point we want to make is that framework development is teamwork, so a framework browser must support working in teams.

Framework Browser Requirements

Traditional hypermedia systems use static point-to-point links to structure navigation relationships, which means that the author of a hypermedia system must maintain the connections between the sources and targets of the links manually. However, in environments where those relationships change often, static links become a maintenance nightmare. One way to deal with dynamic structures is to have some kind of smart links that use knowledge about the information to infer relationships. In the scene, Patrick would create a "smart link" that uses internal data structures of the implementation environment to return all occurrences of the message implementing the design.

A framework browser should be able to incorporate smart links incorporating knowledge from inside the implementation environment ([OHS-REQ 4]: Data Models).

To implement tele-presence, the system must ensure integrity between different viewers, simultaneously manipulating the same data. This implies that the framework browser must be able to monitor open, change and close events and pass them to other viewers. Those viewers are in principle unaware of each other and may or may not run on the same machine.

A framework browser should be able to trap important events and notify other viewer applications, irrespective of the type or number of viewers involved ([OHS-REQ 6]: Users).

Our Results

Zypher is equipped with a fully extensible link engine and we have plugged in algorithms for "smart links" between analysis and design documentation on the one hand and the implementation on the other hand. Analysis and design documents may include HTML style anchors with a special "browse:" keyword. This keyword identifies a smart link referring to an element of the implementation. Possible references are "system" (to open the global system browser), "class X" (to open a class browser on the class X), "class X method Y" (to open a method browser on the method Y in class X), "sendersOf X" (to browse all methods that send the message X), "implementorsOf X" (to browse all methods that implement the message X).

Zypher does not include any facilities for concurrent users, so we could not yet demonstrate tele-presence. However, the Zypher framework comes with a meta-object protocol that allows us to trap all open, close and change events and we implemented a layered event passing mechanism on top of it. Using this mechanism, we have been able to synchronise two home cooked viewers (i.e. HTML and text) that are completely unaware of each other. When we save a HTML representation in a certain text file using the simple text viewer, the HTML viewer opened on the same text file updates its contents automatically. The same scheme could have been used to synchronise the contents of two third party applications running on the same machine (i.e. the Notepad and Microsoft Word) viewing the same file. Synchronising viewer applications running on different machines is more difficult but would be feasible as well: besides the obvious need for a high level communication channel between the two machines, it would involve an extension of the meta-object protocol to pass events over distributed machines.

Scene 4: Reuse Library

After a few analysis/design/implementation iterations, Patrick and Koen succeed in building two GDSS's; one for a synchronous-proximate setting and one for an asynchronous-distributed setting. Dirk is now testing the software with a number of groups and is quite pleased with how it works.

Patrick and Koen actually build a reusable design for the GDSS domain. However, there solution probably contains parts that may be reused in other CSCW frameworks. They hand over all the analysis, design and implementation to Roel, who is responsible for the identification of reusable assets and for storing them in the computer science department reuse library. To maximise access, this library is accessible via the world-wide web.

Roel studies the received material and via discussions with Patrick and Koen he identifies those parts of the analysis, design and implementation that may be reused in other frameworks. For each reusable asset, he writes a so-called design pattern [GammaEtAl'95], including an analysis section (based on some ideas in the original analysis), a contract section (based on the original design) and an implementation section (including references to the original implementation).

Roel is now ready to store the new design patterns in the library. As far as the design pattern document concerns, this is not so difficult: he relies on the multitude of HTML converters available. The references to the implementation impose a special problem however. The tools supplied with typical programming environments provide a narrow, class-oriented perspectives on class- and object structures. Design patterns are usually spread over several classes and only a few methods matter to understand one particular design pattern. Roel concludes that the tools provided with the programming environment are not suited as viewers for the implementation of design patterns. Roel decides to build special purpose viewers himself, using the tools provided by the open hypermedia system (i.e. a set of components to assemble design pattern views). Moreover, he wants to translate those views into HTML forms, so that the reuse library would accessible through the web.

The design pattern library gets larger and larger, and Roel encounters consistency maintenance problems. A design pattern does not work alone, but is supposed to be used in combination with others. However, it is quite difficult to manage links between design patterns that are known to be working together. Roel decides to use the extensible link engine of the open hypermedia system to plug in special algorithms that help in managing the consistency of the library. The idea is that if design patterns work together, the implementations of both design patterns will overlap to some extent. Roel extends the hypermedia system so that when a new design pattern is added, its contents is scanned for all references to the implementation and those references are stored inside a special database. This database is used to infer relationships between design patterns that use the same implementation.

Goal(s) of this Scene

"Framework Goal. Set up a structure in which to plan and manage the process of acquiring, distributing, and maintaining reusable assets throughout the organisation."([ Goldberg,Rubin'95], p.223)

This scene illustrates the different approaches towards reuse within one framework and reuse across frameworks. To accomplish the latter, some kind of reuse library must be set up. There again --certainly with the advent of the world-wide web-- an open hypermedia system can play an important role to make the library easy accessible.

Character(s)

Roel is the so-called reuse librarian ([Goldberg,Rubin'95], p.500), responsible for certifying, classifying, and storing new reusable assets in the corporate or project library. Much of the reuse assets in the library are based on the design pattern catalogue published in [GammaEtAl'95] although Roel collected many domain specific design patterns as well.

Framework Browser Requirements

Being able to call upon services of third party applications to view information is one of the selling arguments for an open hypermedia system. Yet, third party viewer applications are not always able to show the desired information, partly because this information is stored within the link structures managed by the hypermedia system. So an open hypermedia system must provide facilities that allow the hypermedia author to build its own viewer applications easily, probably based on some kind of componentware approach.

A framework browser needs powerful, easy-to-use programmable tools for building specialised viewer applications ([OHS-REQ 2]: Data Formats, [OHS-REQ 4]: Data Models).

The world-wide web is reaching the status of a universal exchange medium. An open hypermedia system should make it easy to exchange information with the world-wide web.

A framework browser must be able to exchange information over the world-wide web ([OHS-REQ 2]: Data Formats).

To support a library function in a framework environment, an open hypermedia system needs tools to link a new library item with the items already in the library.

A framework browser should be able to incorporate smart links to support consistency maintenance in large reuse libraries ([OHS-REQ 1]: Size, [OHS-REQ 4]: Data Models).

Our Results

Zypher comes with a library of components that can be assembled programmatically to form new code browsers. We plan to integrate these components with the ApplFLab environment to attain a componentware approach (i.e. similar to [Wuyts'96]). Using VisualWave (a Smalltalk tool for generating HTML forms out of Smalltalk window specifications) we can publish these code browsers on the web quite easily.

To support the consistency maintenance of the design pattern library, we have extended Zypher's link engine to incorporate knowledge about design patterns. When the librarian stores a new design pattern in the library, he must provide a list of all the messages participating in the corresponding framework contract. All these messages are stored in a special database and Zypher's link engine queries this database to generate a pop-up menu of all related patterns.

References

[Davis,Knight,Hall'94]

Davis, H. C. / Knight, S. / Hall, W. "Light Hypermedia Link Services: A Study of Third Party Application Integration"; in [ECHT'94].

[Davis,Lewis,Rizk'96]

Davis, H. / Lewis, A. / Rizk, A. "OHP: A Draft Proposal for a Standard Open Hypermedia Protocol"; in [Wiil,Demeyer'96]

[Demeyer'96]

Demeyer, S. "Zypher -- Tailorability as a Link from Object-Oriented Software Engineering to Open Hypermedia". Ph.D. dissertation, Faculty of Sciences, Brussels Free University - July, 1996. Available on the world-wide web via http://iamwww.unibe.ch/~demeyer/ and http://progwww.vub.ac.be/prog/papers/paperquery/.

[ECHT'94]

European Conference on Hypertext'94, September 18-23, Edinburgh, UK. Proceedings: ACM Press, 1994.

[GammaEtAl'95]

Gamma, E. / Helm, R. / Johnson, R. / Vlissides, J. "Design Patterns"; Addisson-Wesley, 1995.

[Goldberg'84]

Goldberg, A. "Smalltalk-80, the Interactive Programming Environment"; Addison-Wesley, 1984"

[Goldberg,Rubin'95]

Goldberg, A. / Rubin, K. S. "Succeeding with Objects. Decision Frameworks for Project Management"; Addison-Wesley, 1995"

[HT'91]

Hypertext'91, December 15-18, San Antonio, Texas. Proceedings: ACM Press, 1991.

[Kenis'95]

Kenis, D. "Improving Group Decisions: Designing and Testing Techniques for Group Decision Support Systems Applying Delphi Principles"; Ph.D. at teh University of Utrecht, 1995.

[Malcolm,Poltrock,Shuler'91]

Malcolm, K. C. / Poltrock, S. E. / Schuler, D. "Industrial Strength Hypermedia: Requirements for a Large Engineering Entreprise"; in [HT'91].

[SteyaertEtAl'94]

Steyaert, P. / De Hondt, K. / Demeyer, S. / De Molder, M. "A Layered Approach To Dedicated Application Builders Based On Application Frameworks"; In Patel D. / Sun, Y. / Patel, S. (Ed) "Proceedings of the 1994 International Conference on Object-Oriented Information Systems"; Springer-Verlag, 1995. Available on the world-wide web via http://progwww.vub.ac.be/prog/papers/paperquery/.

[SteyaertEtAl'96]

Steyaert, P. / De Hondt, K. / Demeyer, S. / Boyen, N. "Reflective Application Builders". Published in "Advances in Object-Oriented Metalevel Architectures and Reflection" (Zimmermann, C. - Editor). CRC Press Inc., Boca Raton, Florida, 1996. Available on the world-wide web via http://progwww.vub.ac.be/prog/papers/paperquery/.

[Wiil,Demeyer'96]

Wiil, U. K. / Demeyer, S. (Ed) "Proceedings of the 2nd Workshop on Open Hypermedia Systems - Hypertext'96"; UCI-ICS Technical Report 96-10. Department of Information and Computer Science, University of California, Irvine, CA 92717-3425. See also http://www.iesd.auc.dk/~kock/OHS-HT96/.

[Wuyts'96]

Wuyts, R. "Class-Management using Logical Queries, Application of a Reflective User Interface Builder"; GRONICS'96 Proceedings of the third Groningen International Information Technology Conference for Students; University of Groningen, 1996. Available on the world-wide web via http://progwww.vub.ac.be/prog/papers/paperquery/.