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

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Also known as Dependents or Publish-Subscribe.

2  Problem Description

A common side-effect of partitioning a system into a collection of cooperating classes is the need to maintain consistency between related objects. You don't want to achieve consistency by making the classes tightly coupled, because that reduces their reusability.

For example, many graphical user interface toolkits separate the presentational aspects of the user interface from the underlying application data . Classes defining application data and presentations can be reused independently. They can work together, too. Both a spreadsheet object and bar chart object can depict information in the same application data object using different presentations. The spreadsheet and the bar chart don't know about each other, thereby letting you reuse only the one you need. But they behave as though they do. When the user changes the information in the spreadsheet, the bar chart reflects the changes immediately, and vice versa.

This behavior implies that the spreadsheet and bar chart are dependent on the data object and therefore should be notified of any change in its state. And there's no reason to limit the number of dependent objects to two; there may be any number of different user interfaces to the same data.

The Observer pattern describes how to establish these relationships. The key objects in this pattern are subject and observer. A subject may have any number of dependent observers. All observers are notified whenever the subject undergoes a change in state. In response, each observer will query the subject to synchronize its state with the subject's state.

This kind of interaction is also known as publish-subscribe. The subject is the publisher of notifications. It sends out these notifications without having to know who its observers are. Any number of observers can subscribe to receive notifications.

3  Domain Definitions

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

ConcreteSubject  =  Subject +  subjectState + . . .

ConcreteObserver = Observer + observerState + . . .

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 implements  a skeleton of the  Subject domain.

component Subjects;
type Subject;

     CreateSubject () -> Subject;

     Attach(Subject, Observer) -> nothing;

     Detach(Subject, Observer) -> nothing;

     Notify(Subject) -> nothing;

      . . .

            <<implementations of >>

     CreateSubject( ) = Subject:[ ... ]; 

     Attach(Subject, Observer) = ...;

     Detach(Subject, Observer) = ...;

     Notify(Subject) = ...;

          . . .

end component Subjects;

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


component ConcreteSubjects;
type ConcreteSubject;

     CreateConcreteSubject(Subject)  -> ConcreteSubject;

     GetState(ConcreteSubject) -> nothing;

     SetState(ConcreteSubject) -> nothing;

     Subject(ConcreteSubject)  -> Subject;

       . . .

            <<implementations of >>
     CreateConcreteSubject(subject) = ConcreteSubject:[..subject..state ..];
     GetState(concreteSubject) = [ ... concreteSubject.state...];

     SetState(concreteSubject) = [ ... concreteSubject.state...];

     Subject (concreteSubject) = concreteSubject.subject;

   . . .

end component ConcreteSubjects;


The following component is a skeleton example of an Observer component:


component Observers;
type Observer;

     CreateObserver () -> Observer;

     Update(Observer)  -> nothing;

      . . .

            <<implementations of >>

     CreateObserver( ) = Observer:[ ... ]; 

     Update(Observer) = ...;

          . . .

end component Observers;

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


component ConcreteObservers;
type ConcreteObserver;

     CreateConcreteObserver(Observer) -> ConcreteObserver;

     Observer(ConcreteObserver)       -> Observer;

     Update(ConcreteObserver)         -> nothing;

       . . .

            <<implementations of >>
     CreateConcreteObserver(observer) = ConcreteObserver:[..observer..state..];
     Observer(concreteObserver) = concreteObserver.observer;

      Update(concreteObserver) = [ ... concreteObserver.state...];

        . . .

end component ConcreteObservers;




Back Home Up Next

  Part 5: Design Patterns   Observer


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 04-12-2012 11:53:22   

free hit counter