Home

 

Getting Started with Elisa

Using EDS

Demo's

Tutorials

 

Language Description

1. Lexical Elements
2. Basic Data Types and Expressions
3. Definitions
4. Streams
5. Backtracking
6. Statements and Special Expressions
7. Arrays
8. Lists
9. Descriptors
10. Components
11. Collections
12. Generic Components
13. Terms
14. Categories
15. Types 

16. Built-in Definitions
17. Higher-order Definitions

18. External Interfaces

Index

Data Structures

1. Sequences
2. Examples involving Lists
3. Trees
4. Graphs
5. Searching State Spaces
6. Language Processing
7. Knowledge Representations          

 

Metaprogramming

1. Introduction
2. What are Domain Definitions?

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

   

Back Home Up Next

WHAT IS DOMAIN ORIENTATION?

1 What is a Domain?
2 Domain Definitions
3 Domain Operations
4 Domain Components
5 Domain Testing

Domain Orientation represents a new approach to develop computer software. In the following sextions we will illustrate several aspects of domain orienation. But, first we need to answer the question: What is a domain?

 

1 What is a Domain?

The word 'domain' is often used with different meanings depending on the context.

One use is related to applications belonging to an application domain which share a set of common characteristics. In that sense domain-orientation means that computer programs should be expressed in notions belonging to an application domain instead of computer related terms. This means that domain-orientation requires a higher level of abstraction.

Sometimes people are talking about a problem domain in contrast to the solution domain. In that context domain-orientation means that the solutions should be expressed in terms of the problem domain.

In mathematics, a domain is the set of elements to which a mathematical or logical variable is limited, or the set on which a function is defined.

In our context, a domain is the representation of a concept in the computer. Concepts are abstract notions of things in the real world or in the problem space. Because we want to model concepts in such a way that they can be understood by a computer, we need a method to represent those concepts in a program. For that purpose we will use domains. Domains are defined by domain definitions.

Before domains can be defined first the key concepts in the problem domain should be identified. To illustrate the steps one has to make in domain orientation we will develop a domain implementation for families. We know from daily experience that a family may consists of a father, a mother, and possibly a number of children. So, the key concepts for our mini-application are: father, mother, and children.

 

2 Domain Definitions

After the key concepts have been identified the corresponding domain defintions can be specified. In our example, this is very simple:

	Family = Father + Mother + Children

This is an example of one of the different forms a domain definition may take. In this domain definition, the domain of Family is defined by using three other domains: Father, Mother, and Children. Also these domains should be defined:

	Father = Person
	Mother = Person
	Children = { Person }

All these domains are based on another domain, called Person. At the last line the curly brackets may be read as "some number of".

The domain of a Person should also be defined. In daily life, persons are characterized by name, address, birthdate, and so on. In our example, we will take a simpler view:

	Person = text

It says that a Person domain is characterized by a piece of text. And, because text is a predefined domain, this is the end of the domain derivation sequence.

These five domain definitions will now be used in following steps.

Note: Domain definitions are not the same as Elisa definitions!
Domain definitions are meta-linguistic tools for modeling problem-space concepts.

 

3 Domain Operations

The next step is to specify domain operations for the domains found in the previous step. Domain operations are depending on the meaning of a domain, the meaning of its sub-domains and on the programs which will use these domains.

We will assume in our example that a family starts with no children. That means that a so-called constructor operation for a Family has the following form:

	Family (Father, Mother) -> Family;

This operation creates a new Family with a given Father and Mother. The new Family is returned by the operation.

As families are getting children, we will need an operation to add a child to a family:

	add_Child (Family, Child) -> nothing;

This operation will add a given Child to the Family. The operation will return nothing. As expected, the add_Child operation may be used several times for a given Family.

Let us assume that we are interested in the children of a family. In that case we need the following operation:

	Children (Family) -> multi (Child);

This operation is a multi-value operation. It returns all the Children of the Family.

To complete our list of operations, let us also assume that we are also interested in the father and mother of a family. This will require the following operations:

	Father (Family) -> Father;

and

	Mother (Family) -> Mother;

This concludes the set of operations needed for our mini-application.

 

4 Domain Components

The following step is to implement the domain specifications as specified in previous steps. We will need the domain definitions as developed in the second step, as well as the domain operations as defined in the third step. The result is a domain component.

An implementation for a set of domain definitions and domain operations is based upon the application of design patterns. The application of a design pattern depends on the particular form of a domain definition and the sort of operation. A design pattern makes use of skeletons which prescribe the sequence of language constructs that should be used. These skeletons are defined later on in another document.

For our mini-application a very simple domain component is defined:

component Families;
   type Father = Person;
   type Mother = Person;
   type Child  = Person;
   type Family;
   Family (Father, Mother)   -> Family;
   Father (Family)           -> Father;
   Mother (Family)           -> Mother;
   Children (Family)         -> multi (Child);
   add_Child (Family, Child) -> nothing;
begin
   Family (Father, Mother) = Family:[ Father; Mother; Children = alist (Child) ]; 
   Father (Family) = Family.Father;
   Mother (Family) = Family.Mother;
   Children (Family) = items (Family.Children);
   add_Child (Family, Child) = add (Family.Children, Child);
end component Families; 

This component is an implementation of the Family domain and its associated operations. A component consists of two parts. The first part is the interface-section, the second part is the implementation-section.

The interface-section contains type declarations and operation specifications. The type declarations are derived from the domain definitions. The operation specifications are based upon the domain operations.

The implementation-section contains definitions of the specified operations. The first definition defines the layout and contents of the Family-descriptor which is derived directly from the domain definition of Family. The other operations are using elements of the Family-descriptor. The operations are also using predefined operations for lists: alist which creates an empty list, items which returns all the items of a list, and add which adds a new element to a list.

 

5 Domain Testing

The testing of our mini-application is very simple. We need to define what a Person is, and we have to make clear that we want to use the component for Families. Both are done as follows:

use Families;
type Person = text;

Now we may test our mini system in a dialogue session. We start by defining a new family:

aFamily = Family ("John", "Alice");

Then we are asking the system, what is the new family:

aFamily?

The system will respond with:

Family:[ Father = "John";
         Mother = "Alice";
         Children = { }]

This answer illustrates a very important property of the system. The system knows how internal data should be represented externally. Programs written in other languages often have to use quite a number of output statements to show the internal data. In the Elisa system not only the values but also the structure of the internal data is provided automatically. This facilitates the understanding of the dynamic behavior of software components and it makes testing of programs much easier.

We now will add three children to the family:

add_Child (aFamily, "Albert");
add_Child (aFamily, "Marianne");
add_Child (aFamily, "Jane");

We may now again ask for the composition of the family:

aFamily?

The system will respond with:

Family:[ Father = "John";
         Mother = "Alice";
         Children = { "Albert",
                      "Marianne", 
                      "Jane"}]

Now we want to test another operation of the Families component. We like to known what the children are of the family:

Children (aFamily)?

The system responds with the following answers:

"Albert"
"Marianne"
"Jane"

This illustrates another property of the system. If the evaluation of a query results in more than one answer those answers will be given one after one. In this example three answers are given.

 

Back Home Top of Page Next

            
Introduction

Home | Highlights of Elisa | Integrating Different Paradigms | Getting Started with Elisa | Demo's  | What is Domain Orientation | Bibliography | Copyright | News | Contact | Contents

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:

Domain Modeling | Concepts | Domain Definitions | Domain Operations | Domain Implementations | Systems | Case study: an Order processing system | Case study: an Airport Support system | Domain Orientation versus Object Orientation

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 

 

click tracking

This page was last modified on 27-09-2012 12:11:19   

free hit counter