Getting Started with Elisa

Using EDS




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


Data Structures

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



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


1 Purpose

2 Problem Description

3 Domain Definitions

4 Elisa Components

1  Purpose

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.


2  Problem Description

Consider a context-sensitive help facility for a graphical user interface. The user can obtain help information on any part of the interface just by clicking on it. The help that's provided depends on the part of the interface that's selected and its context; for example, a button widget in a dialog box might have different help information than a similar button in the main window. If no specific help information exists for that part of the interface, then the help system should display a more general help message about the immediate context—the dialog box as a whole, for example.

Hence it's natural to organize help information according to its generality—from the most specific to the most general. Furthermore, it's clear that a help request is handled by one of several user interface objects; which one depends on the context and how specific the available help is.

The problem here is that the object that ultimately provides the help isn't known explicitly to the object (e.g., the button) that initiates the help request. What we need is a way to decouple the button that initiates the help request from the objects that might provide help information. The Chain of Responsibility pattern defines how that happens.

The idea of this pattern is to decouple senders and receivers by giving multiple objects a chance to handle a request. The request gets passed along a chain of objects until one of them handles it.


The first object in the chain receives the request and either handles it or forwards it to the next candidate on the chain, which does likewise. The object that made the request has no explicit knowledge of who will handle it—we say the request has an implicit receiver.

Let's assume the user clicks for help on a button widget marked "Print." The button is contained in an instance of PrintDialog, which knows the application object it belongs to (see preceding object diagram). The following interaction diagram illustrates how the help request gets forwarded along the chain:


In this case, neither aPrintButton nor aPrintDialog handles the request; it stops at anApplication, which can handle it or ignore it. The client that issued the request has no direct reference to the object that ultimately fulfills it.

To forward the request along the chain, and to ensure receivers remain implicit, each object on the chain shares a common interface for handling requests and for accessing its successor on the chain. For example, the help system might define a HelpHandler class with a corresponding HandleHelp operation. HelpHandler can be the parent class for candidate object classes, or it can be defined as a mixin class. Then classes that want to handle help requests can make HelpHandler a parent:


The Button, Dialog, and Application classes use HelpHandler operations to handle help requests. HelpHandler's HandleHelp operation forwards the request to the successor by default. Subclasses can override this operation to provide help under the right circumstances; otherwise they can use the default implementation to forward the request.

3  Domain Definitions

We will transform the top-level relations into a set of corresponding domain definitions:

HelpHandler = {HelpHandler}

Widget = Button | Dialog | . . .

The next step is to translate the domain definitions into a number of Elisa components. In addition, we will use skeletons of definitions as shown in the preceding domain relationships.

4  Elisa components 

Based on the domain definitions a set of related components are derived. The first component describes the interfaces of a HelpHandlers component: 

component HelpHandlers;
type Handler = HelpHandler;

     CreateHandler()    -> Handler;

     HandleHelp(Handler) -> nothing; 

       . . .

            <<implementations of >>

     CreateHandler( ) = Handler:[ list = alist(Handler)...  ];

HandleHelp(Handler) = . . .;

 . . .

end component HelpHandlers;


The following component is a skeleton example of a Widget:


component Widgets;
type Widget = category(Button, Dialog);

     HandleHelp(Widget)-> nothing;

     ShowHelp(Widget)  -> nothing; 

       . . .

            <<implementations of >>
     HandleHelp(Button: button) = HandleHelp(button);

     HandleHelp(Dialog: dialog) = HandleHelp(dialog);


     ShowHelp(Button: button) = ShowHelp(button);

     ShowHelp(Dialog: dialog) = ShowHelp(dialog);

        . . .

end component Widgets;

The following component is a skeleton example of a Button component:


component Buttons;
type Button;

     CreateButton( )   -> Button;
     HandleHelp(Button)-> nothing;

     ShowHelp(Button)  -> nothing; 

       . . .

            <<implementations of >>
     CreateButton( ) = Button:[ ];
     HandleHelp(button) = ...

     ShowHelp(button) = ...; 

        . . .

end component Buttons;


The following component is a skeleton example of a Dialog component:


component Dialogs;
type Dialog;

     CreateDialog( )   -> Dialog;
     HandleHelp(Dialog)-> nothing;

     ShowHelp(Dialog)  -> nothing; 

       . . .

            <<implementations of >>
     CreateDialog( ) = Dialog:[ ];
     HandleHelp(Dialog) = ...

     ShowHelp(Dialog) = ...; 

        . . .

end component Dialogs;


Back Home Up Next

  Part 5: Design Patterns   Chain of Responsibility


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-11-2012 16:57:23   

free hit counter