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


6 SYSTEMS

6.1 The Environment of a System
6.2 Modeling a System
6.3 System Operations
6.4 System Implementation
6.5 Guidelines
6.6 Summary

 

The fifth and final step of the domain modeling process is to model a system in its environment, thereby using the components developed in the preceding chapter.

Systems are not working in isolation but are parts of larger wholes. Computer-based systems are often designed to support or to enhance the activities of the environment in which they are working. One of the tasks in system modeling is to decide which functions should be performed by the system and what kind of services or requests may be expected from the environment. In this chapter we will examine ways to discover systems functions and how they can be modeled.

 

6.1 The Environment of a System

As discussed earlier, the first step in modeling a system is to draw a diagram of the environment of the system. The system itself will be considered as a black box. Such a diagram will show concepts in the real world which are relevant for the system as has been described in Chapter 2. The same diagram can also serve as input for determining the operations of a system.

Let us use, as an example, the environment of a book shop. A book shop has customers which are ordering books, and suppliers which are sending books to a book shop after purchase orders have been received. The environment can be described in the following way (see Figure 6-1).


------------              -------------               ------------
| -------------           |           | Purchase   ------------- |
| |           |  Orders   |           |  Orders    |           | |
| |           | --------> |           | ---------> |           | |
| | Customers | <-------- | Book Shop | <--------  | Suppliers | |
| |           |   Books,  |           |   Books,   |           | |
  |           |  Invoices |           |  Invoices  |           |
  -------------           -------------            -------------

Figure 6-1: The Environment of a Book Shop

This diagram tells us what the key concepts are of a book shop: customers, orders, books, invoices, purchase orders, suppliers. Those key concepts are used in the first modeling steps.

However, the same diagram will also be used in the final modeling step to model the system.

 

6.2 Modeling a System

Besides the key concepts we will find in the environment of a system, the system itself is also a key concept which should be modeled. As we examined in previous chapters, a concept may be modeled by means of domain definitions and domain operations. So, the same should be done for a system.

We start with the domain definition for a system. We use as input the concepts found in the environment of the system. Let us take, as an example, the book shop as described in Figure 6-1. Using the environmental concepts a book shop can be characterized by the following domain definition:

BookShop = Name + Address + Books + Orders + Invoices + Suppliers

Note that BookShop is a composite domain. Most of the element domains are representing concepts in the environment of the system.

Based on the domain definition for a system the domain operations have to be specified. As for all composite domain definitions, the inputs for domain operations are coming from three sources: behavior of concepts in the problem space, the structure of the domain definitions, and the requirements of the users. The same division applies to operations of system domains. For systems, the operations based on user requirements and system behavior are the most important. Because structure related operations can be directly derived from the domain structure we will not discuss those in this section and we will concentrate the discussion on the other operations.

 

6.3 System Operations

Before the operations of a system are specified, a list of possible external events is required. An external event is something that happens at a point in time outside the system which may effect the system. As in input for determining the external events of the system, the actions in the environment of the system should be considered. For example, if we use the environment of a book shop as given by Figure 5-1, the following kinds of external events can be listed:

  • Customer places Order
  • Customer cancels Order
  • Customer sends Payments
  • Supplier sends new Supply

Because an external event may influence the state of the system, we will specify for each kind of event a corresponding system operation which is activated in case the event occurs. For system operations we will use the same notation as used for other domain operations. This means the events list of our book shop example may be translated into the following system operation specifications:

Customer places Order 		=>   Process (BookShop, Order) -> nothing;
Customer cancels Order 		=>   Cancel (BookShop, Order) -> nothing;
Customer sends Payment 		=>   Payment (BookShop, Invoice) -> nothing;
Supplier sends new Supply		=>   Supply (BookShop, Supply) -> nothing;

The result specification of an operation specifies what the system will return. It depends on the operation and the requirements of the users. In our example we assume that nothing will be returned.

Based on the system operations we are now able to specify the interface of a system. For our example it means:

type BookShop;
     BookShop (Name, Address)    -> BookShop;
     Process (BookShop, Order)   -> nothing;
     Cancel (BookShop, Order)    -> nothing;
     Payment (BookShop, Invoice) -> nothing;
     Supply (BookShop, Supply)   -> nothing;

To make the specification complete we introduced the type BookShop and a constructor operation for BookShop. The other operations are derived from the events list. All types are derived from existing concepts.

The BookShop specification allows that several book shops may be modeled, all with the operations as specified above. However, in many system modeling activities only one system need to be modeled. In that case the specification can be simplified:

BookShop (Name, Address) -> nothing;
Process (Order)          -> nothing;
Cancel (Order) 	         -> nothing;
Payment (Invoice) 	 -> nothing;
Supply (Supply) 	 -> nothing;

The type of BookShop has been deleted from this specification.

 

6.4 System Implementation

A system is implemented as a component. The interface section contains the specifications of the system operations as defined in the preceding section. The implementation section contains the corresponding definitions. The system component may use the operations defined by other components as developed in the preceding modeling steps. Examples will be given in following chapters.

 

6.5 Guidelines

The fifth and final step of the domain modeling process is to model a system in its environment, thereby using the components developed in the preceding chapter.

Use the environment of the system to discover the key concepts and the external events.

Consider a system as a key concept, which should be described by a domain definition and domain operations.

Make a list of external events and specify for each kind of event a system operation.

Implement the system as a component.

 

6.6 Summary

  • The fifth and final step of the conceptual modeling process is to model a system in its environment.
  • One of the major tasks in system modeling is to decide which functions should be performed by the system and what kind of services or requests may be expected from the environment.
  • A diagram of the environment of the system can be used to discover key concepts and external events.
  • The system itself is also a key concept which can be described by domain definitions and domain operations.
  • The user related operations are the most important operations of a system.
  • A list of possible external events can be used to discover system operations.
  • A system can be represented by a component.

 

Top of Page   Part 4: Domain Modeling   Chapter 6: Systems

 
            
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 16:49:48   

free hit counter