GUMP

I. Introduction

1. GUMP (GUI Modeling Program) will allow a user to visually create a graphical user interface for an application, without entering actual programming language code.

2. GUMP is part of a larger CASE tool that the rest of the Fall 1998 CPSC 247 class will be developing. This tool is an Integrated Software Engineering (ISE) tool that encompasses various parts of the design of an object-oriented program. It uses a unified model to represent class diagrams, task models and other modeling views, thus bringing them together in one convenient package. As a part of this larger project, GUMP will interface with the unified database substrate that is common to all the parts of this larger tool.

3. GUMP will be written in Java using Sun's JDK 1.1 and using the Swing widget set. It will also build GUI interfaces using the Swing set. It will start the user out with a blank canvas, upon which the user will be able to add buttons, text fields, and other widgets. In addition to being able to add new widgets, the user shall be able to add widgets that have already been created as classes in some other part of the CASE tool.

II. Methodology

III. Risks

1. Miscommunication between the customer and our development team
   Any kind of miscommunication between the customer and our development team will clearly result in a project that does not satisfy the customer's needs. To solve this potential miscommunication problem, we have tried to give a considerable amount of time to meet with our customer and build the requirements needed for this project.

2. Miscommunication between our group and other groups
   Our project depends also on other projects. For example, we will be using a database quite intensively that is to be made by the database team. This requires both groups to have clear enough communication so as to enable us to use their database project appropriately. Miscommunication in this area will be fatal or at least slow down the progress of our project. Since this project is a part of a bigger application, good and clear communication between groups is a must.

3. Miscommunication between team members
   Being at college and having other classes and responsibilities to attend to, we often find it difficult to come together to plan, discuss and code. We will try to do the best we can, but there is always the risk that lack of communication cripples our efforts. We chose the democratic decentralized team structure, and this structure especially requires communication to be high.

4. Bad design
   This particular project can benefit much from good object-oriented design. Proper use of patterns and flexible, well-thought out design can help us add the most features in the least time possible, and do it all elegantly. On the other hand, if we choose a bad design, we will spend most of our time tying up our code with baling wire and duct tape, not implementing real features.

5. Time constraints
   This project is a part of our regular class load this semester. Hence, although we are working as a team, we can never avoid the fact that we will not be able to work full time for this project. This leads to the possibility of an unfinished project. To solve this problem, we will try to finish the most basic part and functionality of this project and if time permits, continue building more and more complex software out of it. Hence, our target during this semester is to at least finish the very basic functionality of our project.

IV. General Requirements

1. The entire ISE project is to be built in Java, because of its cross-platform capabilities.

2. GUMP should be interactive, allowing the user to place widgets on a window with the mouse, and possibly move them around and change their attributes as they wish.

3. GUMP must integrate with the overall ISE project, not simply exist as an independent entity attached to the ISE project merely by association. It must do something useful with the underlying model of the entire project.

4. This is a prototype, so the important thing is to get the basics working. A complete program should not necessarily be the end result of our project. Rather, our client is looking for something that will prove the concept that all these seemingly disparate design processes can be unified.

5. GUMP should be modular, just like the other parts of the overall project. It should not try to do the tasks that belong to other modules or packages.

6. All parts of the ISE project should be easy and intuitive to learn and use. Each part must also have some kind of end-user help built in.

V. Required Features

1. It was explicitly stated by the customer that Java should be used in the construction of this project. The version of Java the GUMP group will use is JDK 1.1, with the Swing Widget Set. Using Sun's JDK will assure the most cross-platform compatibility that can be achieved at this time with Java (that is, it avoids proprietary Java solutions by third parties, such as Microsoft's J++). This program will be rendered as an application, as opposed to an applet; it will not require any other software to run, once it is integrated with the other parts of the ISE tool. (See IV.A.)

2. GUMP must be able to run on any platform with a Java implementation. One of the primary advantages of using Java--"platform independence"--is lost if any machine-dependent functions are called by GUMP. In this spirit, GUMP will be as machine-independent as possible, and will run under any operating system for which the JRE (Java Runtime Environment) or JDK (Java Development Kit) is available. (See IV.A.)

3. GUMP will begin with a blank canvas or frame, on which the user places widget objects. The canvas will be required to visually indicate which widgets it currently contains, and where they will be placed graphically. (See IV.B.)

4. There must be a palette of widgets, minimally including the Swing button and a Selector tool. Clicking on any tool will select it to be used the next time the user clicks on the canvas. (See IV.B.)

5. It is absolutely necessary that GUMP be able to place at least a button on a blank canvas. This object should then be able to be stored in the database substrate. It is not within the scope of GUMP to "save" the objects, but only to instantiate and manipulate objects. The saving and retrieving will be the job of the database project. (See IV.D. and IV.E.)

6. It is also necessary that GUMP be able to use a widget or other GUI object which has been created using the ISE tool's "Class Builder" or "Method Builder." For example, if a button object is created in another part of the ISE tool, it must be accessible in GUMP. (See IV.C.)

7. GUMP will also be required to provide online help, which will provide some level of instruction or context-sensitive assistance should the user desire it. Java has built-in help-creation facilities (JavaHelp) which will be used to implement this requirement. (See IV.F.)

8. GUMP should be set at a Computer Science undergraduate level, and should be easy enough for users at this level to use with a small amount of instruction or experimentation. (See IV.F.)

9. GUMP must implement an interface for saving its model to the database and restoring it as it was before. This interface is developed by the database substrate group. (See IV.C.)

10. Finally, it is required that the working prototype of GUMP be entirely finished by the assigned date in December, and should at this time implement all of the required functionality and as much of the desired functionality as possible. (See IV.D.)

VI. Desired Features

1. GUMP should be able to produce the code "stubs" corresponding to the GUI the user has just designed. Its code generator should be modular, separate from the rest of the GUMP model. Therefore, it should couple more directly with the substrate that underlies the entire ISE project.

2. There are many widgets in the Swing Widget Set, and as many will be integrated into and accessible from GUMP as possible. However, due to time constraints, it will most likely not be possible to include them all. These Widgets include radio buttons, checkboxes, pull-down lists, and so on.

VII. Extra Features

1. Layout managers are an essential part of a good Swing GUI. Our first prototype will most likely use absolute positioning, as it is easier for us to work with. However, if we have the time, it would be nice to implement some mechanism by which the user can assign a layout manager to a frame, and then position widgets within the cells of that layout manager.

2. Some widgets are capable of containing other widgets. It would be nice to build into GUMP the capability to put child widgets on these widgets. This is somewhat similar to the layout manager feature.

VIII. References