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

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.


2 Problem Description


Graphics applications like drawing editors and schematic capture systems let users build complex diagrams out of simple components. The user can group components to form larger components, which in turn can be grouped to form still larger components. A simple implementation could define classes for graphical primitives such as Text and Lines plus other classes that act as containers for these primitives.

But there's a problem with this approach: Code that uses these classes must treat primitive and container objects differently, even if most of the time the user treats them identically. Having to distinguish these objects makes the application more complex. The Composite pattern describes how to use recursive composition so that clients don't have to make this distinction.

The key to the Composite pattern is an abstract class that represents both primitives and their containers. For the graphics system, this class is Graphic. Graphic declares operations like Draw that are specific to graphical objects. It also declares operations that all composite objects share, such as operations for accessing and managing its children.

The subclasses Line, Rectangle, and Text (see preceding class diagram) define primitive graphical objects. These classes implement Draw to draw lines, rectangles, and text, respectively. Since primitive graphics have no child graphics, none of these subclasses implements child-related operations.

The Picture class defines an aggregate of Graphic objects. Picture implements Draw to call Draw on its children, and it implements child-related operations accordingly. Because the Picture interface conforms to the Graphic interface, Picture objects can compose other Pictures recursively.

The following diagram shows a typical composite object structure of recursively composed Graphic objects:


3 Domain Definitions

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

 Graphic = ... | Line | Rectangle | Text | Picture 

 Picture = ... + { Graphic } + ... 

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 class relationships.

4 Elisa components

Based on the domain definitions a set of related components are derived.

The first domain definition is a selection domain. It specifies a number of alternative domains. The implementation of selection domains is based on the concepts of categories.  The following component implements the Graphic = Line | Rectangle | Text | Picture .

component Graphics;
type Graphic = category(Line, Rectangle, Text, Picture);
     Draw(Graphic)            -> optional(boolean);
     Add(Graphic, Picture)    -> nothing;
     Remove(Graphic, Picture) -> boolean;
     GetChildren(Graphic)     -> multi(Graphic);

        . . .
     Draw(Line:line)           = Draw(line);
     Draw(Rectangle:rectangle) = Draw(rectangle);
     Draw(Text:text)           = Draw(text);
     Draw(Picture:picture)     = Draw(picture);

     Add(graphic, picture)         = Add(picture, graphic);
     Remove(graphic, picture)      = Remove(picture, graphic);

     GetChildren(Picture: picture) = GetChildren(picture);
        . . .

end component Graphics;

The definitions in this component use  patterns for dynamic type matching to select the definition rule which corresponds to the matching type. 

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

component Lines;
type Line;
     CreateLine( ) -> Line;
     Draw(Line)    -> boolean;

      . . .
            <<implementations of >>
     CreateLine( )= ...;
     Draw(line)   = ...;

      . . .
end component Lines;

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

component Rectangles;
type Rectangle;
     CreateRectangle( ) -> Rectangle;
     Draw(Rectangle)    -> boolean;

      . . .
            <<implementations of >>
    CreateRectangle( ) = ...;
    Draw(rectangle)    = ...;

       . . .
end component Rectangles;

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

component Texts;
type Text;
     CreateText( ) -> Text;
     Draw(Text)    -> boolean;

        .  .  .  
            <<implementations of >>
     CreateText( ) = ...;
     Draw(text)    = ...;

       . . .
end component Texts;

The following component is an example of a Picture = { Graphic }  component. It specifies a number of repetitive domains. A repetitive domain represents a collection of items. In Elisa it may be implemented as an array, a list, or any other kind of a collection, such as a sequence, a tree, or a database. In the  Pictures component, we will assume that repetitive domains are implemented as lists.

component Pictures;
type Picture;
     CreatePicture( )         -> Picture;
     Draw(Picture)            -> boolean;
     Add(Picture, Graphic)    -> nothing;
     Remove(Picture, Graphic) -> boolean;
     GetChildren(Picture)     -> multi(Graphic);

            . . .

            <<implementations of >>
     CreatePicture( )         = Picture:[ GraphicList = alist(Graphic); ... ];
     Draw(picture)            = Draw(items(picture.GraphicList);

     Add(picture, graphic)    = add(picture.GraphicList,graphic);

     Remove(picture, graphic) = ... ;

     GetChildren(picture)     = items(picture.GraphicList); 

            . . .

end component Pictures;



Back Home Up Next

  Part 5: Design Patterns   Composite


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 17:02:10   

free hit counter