When you use a parallel development approach to team development, you separate the application into distinct modules, which different developers can work on in parallel, using separate G2 licenses. Each developer is responsible for developing a single module at a time, and you share copies of the supporting modules among the various developers. Periodically, you merge all the modules together into a new master KB, which you then redistributed among all the developers.
For more information on using parallel development in a team development environment, see Using a Master KB for Parallel Development.
Allows Separation of the GUI from the Core
You might want to create a separate user interface module to:
Supports Encapsulation
Modules support object-oriented design principles by encapsulating related information in a single location and exposing only the publicly supported API to the rest of the application. The details of the module's implementation remain hidden to clients that wish to use the module.
Encourages Code Reuse
By defining your application as a set of well-defined modules, you encourage reuse of potentially large portions of your application. Reusing code saves development time and leverages existing knowledge within a large organization.
Provides Self-Documentation
The way an application is organized can provide an implicit form of internal documentation for developers. For example, by creating a module with a specific purpose and with a well-defined API, you are implicitly documenting the public behavior of the module - how the module should behave and what features are available to other modules in the application. Similarly, by organizing your application into modules that support a particular set of features, you are implicitly documenting the private behavior of the module - which definitions the features require in order to function. Supports Testing
Depending on how you have implemented your module hierarchy, you can test various modules independently of other modules. If a module depends on another module, you can test just the dependent modules separately. Also, if you implement a fully functional API for your module, you can test your module programmatically. Finally, modularizing your application decreases debugging time and limits the impact of code modifications.
Supports the Use of Standard G2 Utilities
Your application can include existing G2 modules as part of the module hierarchy. G2 supports numerous stand-alone modules that provide additional functionality to your application. All of these stand-alone modules are available to you in the /kbs subdirectory of your G2 directory.
For more information on the other G2 utilities, see Chapter 9, Building a User Interface.