Modularizing Your Application
Designing Reusable Modules
One of the goals of software development is to design components that other members of your development team or other departments within your organization can reuse. A well designed module that is intended for reuse typically has:
In addition to these external features, the module must implement the core functionality and the functionality of the user interface.
This section describes two alternative architectural designs for reusable modules:
Both architectures keep the user interface and the API separate from the implementation, which supports encapsulation and can enhance performance.
The four-layer, two module architecture also separates the GUI from the core component by placing it in a separate module. This architecture is the more flexible because it allows you to replace the G2 GUI, which you implement by using G2 components and utilities, with a native user interface, which you implement using native GUI-building tools and standards such as CORBA, Active X/COM, and Java/RMI.
Separating the Module into Layers
Both four-layer architectures structure modules into layers. Each layer interacts only with the layer directly below it or with public procedures in required modules.
You designate the layers as either public or private, as follows:
Because G2 does not provide a direct mechanism for distinguishing between public and private knowledge, you implement the public/private distinction by:
Note that a public class can have private attributes or a mixture of public and private attributes, as explained in Defining Private Knowledge for Public Classes.
The Four-Layer Architecture
The four layers in the four-layer architecture consist of:
- Graphical user interface (GUI) layer (public)
The GUI layer is a public layer that includes the dialogs, menus, and object instances with which the user directly interacts. You can think of the GUI layer as a graphical "view" of the core layer. When the user interacts with the GUI, the GUI layer calls methods, procedures, and rules in the GUI implementation layer.
- GUI implementation layer (private)
The GUI implementation layer is a private layer that contains the procedures, menu choices, master dialogs, and menu templates, that generate user interface elements and respond to user input. When user input causes methods, procedures, or rules in the GUI implementation layer to execute, the GUI implementation layer can call methods and procedures in the API layer.
- Application programmer's interface (API) layer (public)
The GUI implementation layer is a public layer that interacts with the functional elements of the module through the API layer, which is also directly accessible to the end user through programmatic calls. When the GUI implementation layer calls methods and procedures in the API layer, the core layer executes methods, procedures, and rules, which perform the actual work of the module.
- Core functionality implementation layer (private)
The core functionality layer is a private layer that contains the internal functionality of the module, which are inaccessible to the user.
Note: A user of the module may never reference directly a module's private GUI implementation or core functionality layers.
This diagram illustrates the four-layer architecture:
This architecture leads to the following implications:
Thus, the API layer includes not only public methods and procedures that interact with the core, it also includes public attributes and methods on public classes.
While, in general, procedure calls add performance overhead, this overhead is not significant and will not impact the performance of the GUI perceptibly. Furthermore, the trade-off for using API calls to manipulate private data structures is the increased clarity you gain by encapsulating your module into public and private layers.
Benefits of the Separating the Module into Layers
The benefits of separating the module into layers are:
Note: You should only integrate the GUI with the core, as shown in the four-layer architecture, if you are certain that you never plan to migrate the user interface to another implementation. Otherwise, you should separate the GUI from the core, as the next section outlines.
Separating the GUI from the Core
User interfaces are in a state of rapid evolution and change. In many applications, GUIs must evolve as user requirements, platforms, and standards change. By contrast, the underlying core functionality is subject to less rapid evolution. In other cases, users might want to use the core functionality but wish to provide their own GUI.
G2 supports embedded GUI-building tools such as GFR, GUIDE/UIL, GMS, GXL. In addition, G2 allows you to distribute your application on the World Wide Web, by using G2 WebLink. Within the Release 5.x timeframe, G2 will also support bridges to native GUI-building development environments and standards such as CORBA, Active X/COM, and Java/RMI. Thus, you might begin by developing your GUI by using embedded tools and eventually migrate to native GUI environments.
For more information on bridges to native GUI environments, see Communicating with Networking Standards and Protocols.
When you develop your application according to the four-layer architecture, you separate GUI components from core functionality, within the same module. The four-layer, two-module architecture goes one step further by separating the GUI from the core by creating two different modules.
Note: We strongly encourage you to adopt the four-layer, two module architecture if you plan to migrate your G2 user interface to a native user interface.
The Four-Layer Two-Module Architecture
The four-layer two-module architecture consists of:
Similar to the four-layer architecture, the implementation layer of the GUI module communicates with the API layer of the core module via API calls.
This architecture leads to this model:
GOLD and GOLDUI, the G2 Online Documentation utility modules, are an excellent example of this architecture. The core functionality module, GOLD, provides the data structures and operations necessary to run online documentation. GOLDUI provides a set of dialogs, which exercises the core functionality. Developers can use the GOLDUI module to develop their own user interface without affecting GOLD in any way.
Benefits of Separating the GUI from the Core
You gain these benefits by separating the GUI from the core, in addition to the benefits you gain by separating your module into layers:
Creating the API
One of the primary reasons for creating a public API to the private core is as a defense against corrupting internal data structures. By guaranteeing that you only pass legal values into the core, you can:
To achieve this, you must create a complete API to the core functionality that allows a GUI to:
For more information about how to construct an API, see Constructing an API.
Creating the GUI
The GUI is a graphical interface to the functionality that the API provides. Thus, the GUI provides interactive access to the core, while the API provides programmatic access.
The GUI typically consists of:
The end user controls the application, provides input data, and takes actions by interacting with these GUI features.
As with your implementation of the API, you should keep the GUI implementation separate from the GUI itself. This means the definitions you use to create the GUI should be in a different layer from the features the end user will see. Also, the objects you use to access data from and provide data to the core should be in a different layer from the GUI features that use the data.
For more information about how to create a user interface, see Chapter 9, Building a User Interface.
Copyright © 1997 Gensym Corporation, Inc.
