Grammar-Oriented Object Design (GOOD) Homepage

What is GOOD?

Grammar-oriented Object Design started with a university registration project around 1983 with H.Mirian and F. Oromchian. This project used an LL(1) parser to drive the execution of the program which would accept input tokens from user input using a scanner that would then submit them to a parser. This parser used a grammar that described the university registration system; specifically its screen flow and back end logic (then on the mainframe).

Around 1989, a set of Computer-based Training systems were built using this grammar-based approach [Arsanjani89]. This evolved into a method for designing object-oriented software. The engine of the CBT did not change, content , questions, pages, te3sts, etc. changed but the core "laws of the training domain" were intact and remained pretty much the same, or were very easy to modify non-intrusively by simply changing the grammar.

Many generative programs were then written: where a grammar-based approach was combined with generating code for every project, to decrease cycle time.

Later, GOOD attempted to address one of the primary risk areas within software engineering -- namely, that of the gulf between business and technical understanding of the architecture is addressed. A business architecture of mapping business architectures to software architectures in an adaptive fashion. There are many ways of using GOOD. One way starts out with defining a domain-specific language for the business domain, as part of extensions to current object-oriented and component-based methods such as the Unified Process or IBM GS Method, and creating a Configurable Workflow for the Enterprise Component's business logic controller. The Business Flow is often implemented inside a Configurable Profile for each component; representing a Product Line Instance.

The e-bazaar project at Maharishi University of Management is a public domain working example of this approach.

Map of Concepts

Here is a mind map of the concepts within GOOD.

Applications

Other applications of GOOD include:

1. Creating Adaptive Objects

2. Building Configurable Workflows

3. Tier-to-tier Mapping in n-tiered software architectures

4. Object Graph Traversal Definition

GOOD starts out by defining the manners of a component-oriented system. Manners are rules governing the behavior of a component or business object, plus the meta-data needed to give it the following properties:

1. Self-decription

2. Dynamic Configuration

3. Dynamic Collaboration

Manners also have to do with Business Rules as First-class Constructs of the component-based paradigm of software development where replaceable, executable parts are defined on the basis of their externally visible ports, connectors and interfaces. A component can be queried for its manners within a given processing context.

GOOD can be used to build Adaptive or Active Object Models. Here is a workshop that will address using Grammar-oriented Object Design in building Adaptive Systems.

The architecture defines a language in which, among other things, the variantions of the product family (product line or business line) may be expressed. For example, if your domain of investigation is telecommunications, and you have many customers subscribed to your various products (Wireless, wireline, internet, cable, DSL, etc.), there will be parameters and variations from the needs of one product to another. You can specify a set of components within that context, that can be wired together in different combinations in order to meet the needs of each product line.

Thus each configuration is a statement in a language about telecommunication [products]. Taking the architecture into detailed design and implementation using GOOD, then involves specifying an often "small" domain-specific language which captures both the baseline of commonality between the products and their variations.

The next step in implementation would be to use or design a (parser) compiler that, given a description (grammar) in the language, assembles the components and allows them to interact in the right way.

In a sense you are defining the business flow language (e.g., workflow) between enterprise components. Use of a graphical language in this context would facilitate adoption and ease of maintenance.