Objects can (or should) be viewed as building blocks, each providing some intrinsic function or value. We have many more objects as building blocks, some quite specialized. Some of these use full encapsulation, while others exploit relatively new interface features, which aid considerably in n-tier environments. All of them have stood the test of time and demonstrated reliable efficacy, and their use and reuse, direct or derived, dramatically speed development, leading to a shorter time-to-market cycle. As powerful and useful as these are, they are only a portion of the parts required to build an application.

Applications development that is done within a unified architecture can more readily exploit Rapid Applications Development tools and capabilities. We do this by using object repository templates, common service objects, and form expression which together constitute a core application base, initially using either SDI or MDI with tabbed child forms.

This is done by recognizing that of many applications, there is a set of common functions and processes whose abstraction can be used to quickly develop new applications based in part on this prior art, with only minor changes to the abstraction that are specific for the new requirements, and that this process can achieve an 80/20 return.

There are five inter-related elements of the RAD architecture for database-driven software applications:

• A Main form, which is the fundamental container for the application
• An application object, which encapsulates common services, and which provides a centralized resource access to all forms in the project
• A package that encapsulates ancillary objects, resources and services
• Varios child forms that encapsulate a logical work unit of the application
• Data modules, each associated with a child form, providing a uniform and consistent interface for data access.

The implementations of these basic RAD elements strictly adhere to one rule: Objects only know about themselves.

A goal of this unified architecture is to allow a PA/PM to create a new project, add the required child forms and their various function components, along with their associated data modules, and then hand the project shell to a coder for adding specific implementations for the application. This implementation in the main consists of adding to, or modifications of, functional and pre-coded stubs in the child form units. In general, the bulk of these changes have to do with entry validation, business rules checking, and work flow conformance. Software development is a creative process, much akin to writing a novel. There is no single right way, but there are a lot of wrong ways.

All of this leads to the FutureWare Frameworks.