Data Structures   3.  Sorts of Domain Definitions 4.  Manipulations of Domain Definitions 5.  Translating Domain Definitions 6.  Dialogue Sessions 7.  Example of Concentric Circles 8.  Example of Domain Substitution applied to Concentric Circles 9.  Example of an Order Processing Application 10.Example of an Airport Information System 11.Example of a Rental Boat Business 12.Benefits of Domain Definitions

##### 4.  Manipulations of Domain Definitions

The translation of concepts into domain definitions is not always a straightforward process. In practical situations, domain definitions are rearranged, or redefined, before a satisfactory set of domain definitions is derived.

After the key concepts of a program have been translated into corresponding domain definitions, it is quite likely that you want to revise the set of domain definitions, either by changing the original definitions or by adding or deleting domain definitions. The result of these manipulations should be a complete and consistent set of definitions. Each definition must be compatible with the syntax of one of the sorts of the listed domain definitions. This means, for example, that the + operator and the | operator may not be mixed in the final version of a domain definition. In this section we will examine two techniques for formal manipulation of domain definitions.

4.1 Substitution of Domain Definitions

The name of a domain in the right hand part of a definition may be substituted by its definition. So, in a set of domain definitions for Person, we may substitute the definitions for Name, Address, and Birthdate:

Person     = Name + Address + Birthdate;

Name       = Firstname + Familyname;

Address   = Street + City + State;

Birthdate = Date;

Substitution gives us:

Person = (Firstname + Familyname) + (Street +  City + State) + Date;

We use parentheses to group domains together; they do not effect the result. The definition is equivalent to:

Person = Firstname + Familyname + Street  + City + State + Date;

By means of this substitution we created a compound Person domain with 6 elements. However, we have lost by this substitution the concepts of Name, Address and Birthdate. Sometimes, this is what we want, because fewer concepts may help to simplify the model. But, sometimes substitution does not help to simplify the model; on the contrary, the loss of a domain name also means losing its semantic meaning. In our example, Date may be interpreted in many different ways, such as birth date, the date when moved to the current address, the date of marriage, and so on. Because Birthdate has a clear meaning, it should not have been substituted.

That substitution can be pushed too far will be even clearer if we continue our substitution process until all domain references have been replaced by their definitions. If we assume that the final domains are all text domains the result will be:

Person = text + text + text + text + text + text;

In this definition all semantic information has disappeared. It is a domain definition without any meaning. So, substitution at the level of the predefined domains makes no sense.

4.2 Introduction of New Domain Definitions

It is also possible to do the inverse of substitution: define new domain definitions and use these new domain names to simplify existing domain definitions. Suppose we have the following domain definitions:

Truck = Make + Year + Mileage + CargoCapacity;

Bus     = Make + Year + Mileage + PassengerCapacity;

These two domain definitions have a number of common domain definitions. We can introduce an additional domain representing the common domain definitions and rewrite the other domain definitions as follows:

Automobile = Make + Year + Mileage;

Truck = Automobile + CargoCapacity;

Bus = Automobile + PassengerCapacity;

In general, introducing a new domain can be useful if the new domain represents a concept that makes sense in the problem domain. Particularly, if the new domain represents a concept belonging to a hierarchy of concepts, as in our example. On the other hand, the introduction of new domain definitions that do not represent concepts in the problem domain may cause problems in successive modeling steps.

 Part 6: Metaprogramming Manipulations of Domain Definitions

 Introduction: Home | Highlights of Elisa | Integrating Different Paradigms | Getting Started with Elisa | Demo's  | What is Domain Orientation | Bibliography | Copyright | News | Contact Language Description: Lexical Elements | Basic Data Types and Expressions | Definitions | Streams | Backtracking | Statements and Special Expressions | Arrays | Lists | Descriptors | Components | Collections | Generic Components | Terms | Categories | Types | Built-in Definitions | Higher-order Definitions | External Interfaces | Index Data Structures: Sequences | Examples involving Lists | Trees | Graphs | Searching State Spaces | Language Processing | Knowledge Representations Domain Modeling: Design Patterns: Introduction | Abstract Factory | Builder | Factory Method | Prototype | Singleton | Adapter | Bridge | Composite | Decorator | Facade | Flyweight | Proxy | Chain of Responsibility | Command | Interpreter | Iterator | Mediator | Memento | Observer | State | Strategy | Template Method | Visitor