GUI & RESOLVE

Index:

Abstract
Calendar
Project Development
Findings and Contributions
Links and References
Return to Europa

Abstract:

Our goal is to integrate RESOLVE ideas into a paradigm for building GUI applications. Some of these RESOLVE ideas include modularization of components and reusability of those components thus allowing for simpler application development and more maintainable software. Our research has focused on separating the components into three basic parts: a model which encapsulates the concrete state of the program; an interface component that does the work of receiving user input and displaying (graphically or textually) whatever is represented in the model; and a controller component which coordinates the actions of both the model and the interface. These components roughly correspond to the components of the more well known Model-View-Controller (MVC) paradigm, but unlike the MVC components, our components will have well defined abstract models.

Calendar:

Autumn 98:

Thorough reseach of MVC ideas
Attempt implementation of a GUI application using MVC paradigm


Winter 99:

Scrap MVC, rethink new ideas
Begin work on a simple application that utilizes our new ideas
...

Project Development:

At first it seemed that the Model-View-Controller (MVC) way of building GUI's could be developed for RESOLVE. Proponents of MVC claim that it separates a program's abstract state space (model) from the output (view) and from the controller. In theory these separate parts would pass information between themselves using some protocol. From our reading, it was sometimes implied and sometimes explicitly stated that MVC components could be swapped. This would mean that a view or controller could be changed without having to alter either of the other two parts. It, however, seemed quite impossible to us that say a particular view could be independent from any given model. To compound this, we could not find any code examples to quell our disbelief. As a result, we have abandoned our hope that MVC is the answer.

Currently, we are exploring the use of RESOLVE toolkit-classes to encapsulate the "interface" part of a GUI applications. The "model" part is being encapsulated in its own class. A "main" application will tie the interface and model together. In developing these components, a heavy emphasis is being placed on using state transitions to drive the program.

As an example, we are in the process of developing a simple counter program. This program's model will simply be an integer. The user interface, which could be text, graphical, or other, will allow the user to do the following: increment the counter, decrement the counter, reset the counter (to zero), and quit the program. The interface will then be responsible for displaying the current counter value.

Findings & Contributions:

methodolgy

This is a generic CCD for our proposed paradigm. In actual code, the components would be as follows: Main_xx -- ".cpp"; UI_xx -- toolkit-class; Model_xx -- class. An interesting property of this CCD is that while any "Main" can use any "Model", each "Main" is tied to a single abstract "UI". (e.g. Main_1 must use something that implements Abstract_UI_1) This is due to the fact that we only see the possibility that there will be one Abstract_Model while there could be many Abstract_UI's

  Return to Europa