Data Structures   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

7 CASE STUDY: AN ORDER PROCESSING SYSTEM

```7.1 Step 1: Key Concepts of Order Processing
7.2 Step 2: Domain Definitions for Key Concepts
7.3 Step 3: Domain Operations
7.4 Step 4: Domain Implementations
7.5 Step 5: Defining the System
7.5.1 Specifying the System Operations
7.5.2 System Implementation
7.5.3 A component for Order Processing
7.6 Testing the model```

In the previous chapters we described five steps of domain modeling and we applied those steps to a number of examples. However, the examples we used were small and limited in scope.

In this chapter we take a more realistic example and will do a case study of an order processing system. We will exercise the different modeling steps and will show how Elisa can be of help in modeling an order processing system in a distribution company. A distribution company may represent your favorite book shop, or a super market, a shop for auto parts or any other enterprise that takes orders from customers and sends purchase orders to wholesalers or manufacturers.

Unfortunately, as almost any case study, also this one is grossly oversimplified and gives only a very limited view of a real-world situation. Nevertheless, we will use this case to demonstrate how the different modeling steps are applied to arrive at a rudimentary order processing system.

7.1 Step 1: Key Concepts of Order Processing

To discover the key concepts of an order processing system we start with a diagram which shows the environment of the system (see Figure 7-1). Mark that this is a generalization of the book-shop environment of Figure 6-1 discussed in the preceding chapter.

```------------               --------------               ------------
| -------------            |            | Purchase   ------------- |
| |           |   Orders   |    Order   |  Orders    |           | |
| |           | ---------> | Processing | ---------> |           | |
| | Customers | <--------- |   System   | <--------  | Suppliers | |
| |           |  Articles, |            |   Supply   |           | |
|           |  Invoices  |            |            |           |
-------------            --------------            -------------```

Figure 7-1: Environment of an Order Processing System

Although the diagram is very simple, it gives us already a lot of information. It tells us what the important key concepts are as a first step of conceptual modeling. For this case, the key concepts are:

Customer
Order
Article
Invoice
Purchase Order
Supplier
Supply

And that concludes the first step. Although, later on, we may discover other key concepts, this is sufficient to begin with the following step.

7.2 Step 2: Domain Definitions for Key Concepts

For each key concept we need to write a domain definition which defines the kind of information that should be recorded about the concept. For our case, we will use the following domain definitions:

Order = Customer + Article + Quantity

Article = Description

Invoice = Order + Amount

PurchaseOrder = Supplier + Article + Quantity

Supply = Supplier + Article + Price + Quantity

Although PurchaseOrder and Supply have a number of common elements, we will not, in this stage, define a common domain, because the meanings of both domains are quite different. If feasible, it may be done later, after we better understand the different implications. In general, avoid the introduction of artificial domains which are not related to concepts in the problem space.

Of this set of domain definitions not all the element domains are defined. Further definitions are needed for some additional domains. We will use, for our case, the most simple versions:

Name = text

Quantity = integer

Description = text

Amount = real

Price = real

And this concludes the second step.

7.3 Step 3: Domain Operations

For each domain definition a set of domain operations must be specified. In our example, we will use only structure related operations. For the composed domain definitions the constructor operations and all the relevant accessor operations are defined. For the mutator operations a selection is made of all the possible mutator operations.

The set of selected domain operations are:

```Customer = Name + Address                                                       << domain definition >>
Customer (Name, Address)           -> Customer; << constructor >>
Name (Customer)                    -> Name;     << accessor >>
```Order = Customer + Article + Quantity                                  << domain definition >>
Order (Customer, Article, Quantity) -> Order;   << constructor >>
Customer (Order)                    -> Customer;<< accessor >>
Article (Order)                     -> Article; << accessor >>
Quantity (Order)                    -> Quantity;<< accessor >> ```
```Article = Description                                                                            << domain definition >>
Article (Description)               -> Article;     << constructor >>
Description (Article)               -> Description; << accessor >>   ```
```Invoice = Order + Amount                                                            << domain definition >>
Invoice (Order, Amount)             -> Invoice; << constructor >>
Order (Invoice)                     -> Order;   << accessor >>
Amount (Invoice)                    -> Amount;  << accessor >> ```
```PurchaseOrder = Supplier + Article + Quantity                                                << domain definition >>
PurchaseOrder (Supplier, Article, Quantity) -> PurchaseOrder; << constructor >>
Supplier (PurchaseOrder)                    -> Supplier;      << accessor >>
Article (PurchaseOrder)                     -> Article;       << accessor >>
Quantity (PurchaseOrder)                    -> Quantity;      << accessor >>   ```
```Supplier = Name + Address                                                         << domain definition >>
Supplier (Name, Address)           -> Supplier; << constructor >>
Name (Supplier)                    -> Name;     << accessor >>
```Supply = Supplier + Article + Price + Quantity                                       << domain definition >>
Supply (Supplier, Article, Price, Quantity) -> Supply;   << constructor>>
Supplier (Supply)                           -> Supplier; << accessor >>
Article (Supply)                            -> Article;  << accessor >>
Price (Supply)                              -> Price;    << accessor >>
Quantity (Supply)                           -> Quantity; << accessor >> ```

And this concludes the third step.

7.4 Step 4: Domain Implementations

The next step is to define implementations for the domain specifications. Because the domain specifications of the preceding step are all based on composed domains with simple domain elements, we can apply to all of them the skeleton of Figure 5-1. Each composed domain definition will be represented by a corresponding Elisa component.

This means that based on the Customer domain specification the following component is derived from the skeleton of Figure 5-1.

```component Customers;
type Customer;
Customer (Name, Address)           -> Customer; << constructor >>
Name (Customer)                    -> Name;     << accessor >>
begin
Name (Customer) = Customer.Name;
end component Customers;```

For the Order domain the following component is derived:

```component Orders;
type Order;
Order (Customer, Article, Quantity) -> Order; << constructor >>
Customer (Order)                    -> Customer; << accessor >>
Article (Order)                     -> Article; << accessor >>
Quantity (Order)                    -> Quantity; << accessor >>
begin
Order ( Customer, Article, Quantity) = Order:[ Customer; Article; Quantity];
Customer (Order) = Order.Customer;
Article (Order)  = Order.Article;
Quantity (Order) = Order.Quantity;
end component Orders;```

The Article domain is represented by:

```component Articles;
type Article;
Article (Description) -> Article; << constructor >>
Description (Article) -> Description; << accessor >>
begin
Article ( Description) = Article:[ Description];
Description (Article)  = Article.Description;
end component Articles;```

Based on the Invoice domain specification the following component is derived:

```component Invoices;
type Invoice;
Invoice (Order, Amount) -> Invoice; << constructor >>
Order (Invoice) -> Order; << accessor >>
Amount (Invoice) -> Amount; << accessor >>
begin
Invoice ( Order, Amount) = Invoice:[ Order; Amount];
Order (Invoice) = Invoice.Order;
Amount (Invoice) = Invoice.Amount;
end component Invoices;```

For the PurchaseOrder domain specification the following component is derived from the skeleton of Figure 5-1:

```component PurchaseOrders;
type PurchaseOrder;
PurchaseOrder (Supplier, Article, Quantity) -> PurchaseOrder; << constructor >>
Supplier (PurchaseOrder) -> Supplier; << accessor >>
Article (PurchaseOrder) -> Article; << accessor >>
Quantity (PurchaseOrder) -> Quantity; << accessor >>
begin
PurchaseOrder ( Supplier, Article, Quantity) = PurchaseOrder:[ Supplier; Article; Quantity];
Supplier (PurchaseOrder) = PurchaseOrder.Supplier;
Article (PurchaseOrder) = PurchaseOrder.Article;
Quantity (PurchaseOrder) = PurchaseOrder.Quantity;
end component PurchaseOrders;```

The Supplier domain is represented by the following component:

```component Suppliers;
type Supplier;
Supplier (Name, Address) -> Supplier; << constructor >>
Name (Supplier) -> Name; << accessor >>
begin
Name (Supplier) = Supplier.Name;
end component Suppliers;```

The Supply domain is represented by the following component:

```component Supplies;
type Supply;
Supply (Supplier, Article, Price, Quantity) ->Supply;<<constructor>>
Supplier (Supply) -> Supplier; << accessor >>
Article (Supply) -> Article; << accessor >>
Price (Supply) -> Price; << accessor >>
Quantity (Supply) -> Quantity; << accessor >>
begin
Supply ( Supplier, Article, Price, Quantity) = Supply:[ Supplier; Article; Price; Quantity];
Supplier (Supply) = Supply.Supplier;
Article (Supply) = Supply.Article;
Price (Supply) = Supply.Price;
Quantity (Supply) = Supply.Quantity;
end component Supplies;```

In addition to the components for composite domains also the equivalent domain definitions must be represented in Elisa. According to the rules given in Section 5.8, "Implementation of Equivalent Domains", the following type definitions, based on the corresponding domain definitions, are required:

```type Name = text;
type Quantity = integer;
type Description = text;
type Amount = real;
type Price = real;```

These type definitions will also be included in a so-called coupler component:

```component CouplerOrderProcessing;
type Name = text;
type Quantity = integer;
type Description = text;
type Amount = real;
type Price = real;
begin
<< empty implementation section >>
end component CouplerOrderProcessing;```

A coupler component provides all the remaining definitions which are necessary for the system; it couples all the components of the system.

And this concludes the fourth step.

7.5 Step 5: Defining the System

The next step is to define the system as discussed in Chapter 6. This step consists of two sub-steps. The first task is to determine the system operations. The second task is to define an implementation of these system operations.

7.5.1 Specifying the System Operations

We start with the task to determine the system operations. Based on the diagram describing the environment of the system (see Figure 7-1), we may conclude that two external events are influencing the system:

• Customer sends Order
• Supplier sends new Supply

This events list can be translated into two system operation specifications:

`Customer sends Order 		=> Process (System, Order) -> nothing;`
`Supplier sends new Supply		 => NewSupply (System, Supply) -> nothing;`

So, the system operations for our order processing system are:

```type OrderProcessingSystem;
Process (OrderProcessingSystem, Order) -> nothing;
NewSupply (OrderProcessingSystem, Supply) -> nothing;```

Note, that we have introduced a new type, OrderProcessingSystem, and that we are using two existing types, Order and Supply.

Because we don't want to model several order processing systems but only one, the type OrderProcessingSystem is not needed. Hence, we may simplify the system operation specifications into:

```Process (Order) -> nothing;
NewSupply (Supply) -> nothing;```

And this concludes the first task to determine the system operations of our order processing system.

7.5.2 System Implementation

Our second task is to define an implementation of the system. At the systems level, we have first used the externals of the system as described by Figure 7-1 to determined the system operations. The next step is to look inside the system to see what the internal activities are.

However, before that can be done it is necessary to know what kind of distribution company we are talking about. A distribution company may have stocks of articles as many shops do, or it has no stocks if it is, for example, a trading company. In the following we will assume that the company has inventories of most used articles. Based on this assumption, we are now able to draw a diagram for the activities inside the order processing system ( see Figure 7-2).

```          --------------------------------------------------
|    ----------    ------------    ----------    | Purchase
Orders ---|--> | Verify | -> |  Check   | -> |Prepare |    | Orders
|    | Orders |    |Inventory |    |Purchase|----|---------->
|    ----------    ------------    | Orders |    |
Notify <--|--------|               |         ----------    |
Customer  |                        |                       |
|                  ------------    ----------    |
|                  | Prepare  |    | Accept |    |
<---------|------------------| Invoices;| <- |  New   | <--|-----------
Articles,|                  |   Ship   |    | Supply |    | Supply
Invoices |                  ------------    ----------    |
--------------------------------------------------```

Figure 7-2: Inside an Order Processing System

Most of the activities are self-explanatory. Because of the interactions with concepts in the environment of the system we will discuss a number of these activities in detail.

Processing of an incoming order involves a number of steps: the first step is to verify if an order is a valid order. The activity "Verify Orders" should at least verify if ordered articles exist. This will require that there is a list of available articles, which we will call ArticlesList. In many shops where customers are giving their orders verbally this will be sufficient. However, if the enterprise is a larger company with a known customer base such as a garage or bank it is also necessary to check if the customer is a known customer. In that case there is a need for a CustomersList. One of the questions here is what should happen if a customer is unknown. Should it be added to the CustomersList as a new customer, as a temporary customer or should the order been refused. This kind of questions should be answered in the analysis phase because a conceptual model depends very much on the answers of such questions.

In our example, we will assume that the existence of articles is checked and that the customer will be notified in case the article is unknown:

```Verify ( Order) -> nothing;
Verify ( Order) = message ("T customer: unknown article", Order)
when ~ member (Article (Order), ArticlesList);```

The interface with the outside world is provided by the message function which has been discussed earlier.

The member function is a polymorphic function which checks if an entity is in the specified list:

```member (entity1, list (entity1)) -> boolean;
member (E, L) = [ if E == items (L) then return (true);
false];```

The next activity in our diagram (see Figure 7-2) is "Check Inventory" which verifies if the requested quantity of the article is in stock. This means that this operation needs access to a list of all the articles in stock together with their quantities. We will call that an InventoryList.

The concept of Inventory is a new one which has not been recognized before. The reason that we have not discovered it earlier, is, that it is an internal concept of the system; it is not mentioned in the environment of the system. This is an example of new concepts which are discovered during further modeling activities. In such a situation we will repeat all the foregoing steps for such a new concept. For our example it means:

Step 1: Add Inventory to the concepts list.

Step 2: Define a domain definition for the new concept. In our case we will use:

Inventory = Article + Price + Quantity

Step 3: Specify the domain operations. For Inventory this will be:

Inventory (Article, Price, Quantity) -> Inventory;
Article (Inventory) -> Article;
Price (Inventory) -> Price;
Quantity (Inventory) -> Quantity;
change_Quantity (Inventory, Quantity) -> nothing;

Step 4: Define an implementation. For Inventory we will use the following implementation:

```component Inventories;
type Inventory;
Inventory (Article, Price, Quantity) -> Inventory;
Article (Inventory) -> Article;
Price (Inventory) -> Price;
Quantity (Inventory) -> Quantity;
change_Quantity (Inventory, Quantity) -> nothing;
begin
Inventory ( Article, Price, Quantity) = Inventory:[ Article; Price; Quantity];
Article (Inventory) = Inventory.Article;
Price (Inventory) = Inventory.Price;
Quantity (Inventory) = Inventory.Quantity;
change_Quantity (Inventory, Quantity) =
[ Inventory.Quantity:= Inventory.Quantity + Quantity ];
end component Inventories;```

In addition to the basic Inventory operations as specified in the preceding component we also need a search operation for the inventory of an article in the InventoryList. This operation is defined as follows:

```CurrentInventory ( Article) -> optional (Inventory);
CurrentInventory ( Article) = [ Inventory = items (InventoryList);
accept ( Article (Inventory) == Article);
Inventory];```

The CheckInventory operation may now be specified as follows:

```CheckInventory ( Order) -> nothing;
CheckInventory ( Order) =
[ Inventory = CurrentInventory (Article (Order));
if Quantity (Order) < Quantity (Inventory) then
[ change_Quantity (Inventory, - Quantity (Order));
PrepareInvoice (Order, Price (Inventory)) ]
else
[ PreparePurchaseOrder (Inventory, Quantity (Order));
message ("To customer: delivery is delayed", Order) ] ];```

The CheckInventory definition determines the current inventory of the ordered article. If the ordered quantity is in stock, the requested number of articles can be delivered immediately out of stock. In that case, the stock level must be updated and an invoice is prepared. If there are not enough articles in stock, a purchase order to the supplier will be issued and the customer will be informed of a delayed delivery.

The PrepareInvoice definition prepares an invoice which will be given to the customer. Although in practice the handling of invoices can be quite complicated (because of tax requirements and interactions with financial management), we will use only a very simple version of the PrepareInvoice operation:

```PrepareInvoice ( Order, Price) -> nothing;
PrepareInvoice ( Order, Price) =
[ Invoice = Invoice (Order, real (Quantity (Order)) * Price);
message ("To customer: Articles have been shipped", Invoice) ];```

An Invoice will be recorded in a InvoicesList. The prepared invoice can now be sent to the customer.

As we have seen, if there are not enough articles in stock, a purchase order will be given. Also here we will use a very simple version of a PreparePurchaseOrder operation:

```PreparePurchaseOrder ( Inventory, Quantity) -> nothing;
PreparePurchaseOrder ( Inventory, Quantity) =
[ PurchaseOrder = PurchaseOrder (Supplier (Inventory),
Article (Inventory), Quantity);
message ("To supplier: Please, send me:", PurchaseOrder) ];```

A purchase order will be recorded in a PurchaseOrdersList. The purchase order can now be sent to the supplier.

However, this PreparePurchaseOrder definition will not work with the current set of components. To prepare a purchase order it is necessary to know the supplier of an article. But that information is not available in our Inventory component. This is another example that when conceptual design progresses, revisions of previous steps are sometimes needed. In our example, we have to revise the steps we used earlier to arrive at the Inventory component in order to include also the Supplier information:

Step 2: Add the Supplier information to the Inventory domain definition:

Inventory = Article + Supplier + Price + Quantity

Step 3: Revise the constructor operation in the following way:

Inventory (Article, Supplier, Price, Quantity) -> Inventory;

Specify an additional domain operation to access the Supplier:

Supplier (Inventory) -> Supplier;

Step 4: Adapt the implementation. For Inventory we will use the follow- ing implementation:

```component Inventories;
type Inventory;
Inventory (Article, Supplier, Price, Quantity) -> Inventory;
Article (Inventory) -> Article;
Supplier (Inventory) -> Supplier;
Price (Inventory) -> Price;
Quantity (Inventory) -> Quantity;
change_Quantity (Inventory, Quantity) -> nothing;
begin
Inventory ( Article, Supplier, Price, Quantity) =
Inventory:[ Article; Supplier; Price; Quantity];
Supplier (Inventory) = Inventory.Supplier;
Article (Inventory) = Inventory.Article;
Price (Inventory) = Inventory.Price;
Quantity (Inventory) = Inventory.Quantity;
change_Quantity (Inventory, Quantity) =
[ Inventory.Quantity:= Inventory.Quantity + Quantity ];
end component Inventories;```

With this component purchase orders can be prepared.

The "Accept New Supply" box from Figure 7-2 is activated when the supplier has sent the requested articles as specified by a purchase order. The incoming articles, together with their invoices should be checked against the corresponding purchase orders and after acceptance of the articles the inventory information should be updated and open customer orders should be satisfied. In order to keep our example simple, we will only update the inventory list, as defined in the following definition:

```NewSupply (Supply) -> nothing;
NewSupply (Supply) =
[ Article = Article (Supply);
Inventory = Inventory (Article, Supplier (Supply), Price (Supply), Quantity (Supply));
add (Article, ArticlesList) when ~ member (Article, ArticlesList);

A new Article is added to the ArticlesList and the new supply is added to the InventoryList.

7.5.3 A component for Order Processing

We are now able to define a component which represents the operations of order processing (see Figure 7-3).

```component OrderProcessing;
Process (Order) -> nothing;
NewSupply (Supply) -> nothing;
Overview ( ) -> list (term);
begin
use Inventories;```
```  ArticlesList       = alist (Article);
InventoryList      = alist (Inventory);
InvoicesList       = alist (Invoice);
PurchaseOrdersList = alist (PurchaseOrder);```
```  DataBase = { term: ArticlesList,
InventoryList,
InvoicesList,
PurchaseOrdersList };```
`  Overview ( ) = DataBase;`
`  Process (Order) = [ Verify (Order); CheckInventory (Order) ];`
```  Verify ( Order) -> nothing;
Verify ( Order) = message ("To customer: unknown article", Order)
when ~ member (Article (Order), ArticlesList);```
```  CurrentInventory ( Article) -> optional (Inventory);
CurrentInventory ( Article) = [ Inventory = items (InventoryList);
accept ( Article (Inventory) == Article);
Inventory];```
```  CheckInventory ( Order) -> nothing;
CheckInventory ( Order) =
[ Inventory = CurrentInventory (Article (Order));
if Quantity (Order) < Quantity (Inventory) then
[ change_Quantity (Inventory, - Quantity (Order));
PrepareInvoice (Order, Price (Inventory)) ]
else
[ PreparePurchaseOrder (Inventory, Quantity (Order));
message ("To customer: delivery is delayed", Order) ] ];```
```  PrepareInvoice ( Order, Price) -> nothing;
PrepareInvoice ( Order, Price) =
[ Invoice = Invoice (Order, real (Quantity (Order)) * Price);
message ("To customer: Articles have been shipped", Invoice) ];```
```  PreparePurchaseOrder ( Inventory, Quantity) -> nothing;
PreparePurchaseOrder ( Inventory, Quantity) =
[ PurchaseOrder = PurchaseOrder (Supplier(Inventory), Article(Inventory), Quantity);
message ("To supplier: Please, send me:", PurchaseOrder) ];```
```  NewSupply (Supply) -> nothing;
NewSupply (Supply) =
[ Article = Article (Supply);
Inventory = Inventory (Article, Supplier(Supply), Price(Supply), Quantity(Supply));
add (Article, ArticlesList) when ~ member (Article, ArticlesList);
```  member (entity1, list (entity1)) -> boolean;
member (E, L) = [ if E == items (L) then return (true);
false];```
```  message (text, entity1) -> nothing;
message (T, E) = logln(Message (T, E) ); ```
`  Message (text, entity1) => term;`
`end component OrderProcessing;`

Figure 7-3: Component for Order Processing

This component defines the operations related to order processing. Its interface with the outside world is the Process(Order) function which processes the incoming orders, and the NewSupply function, which accepts new articles from the supplier.

Internally, there are four lists: the ArticlesList, the InventoryList, the InvoicesList and the PurchaseOrdersList. Together they are forming the database of the company. The associated Overview function will be discussed later on.

7.6 Testing the model

What we have done so far is building a domain model of an order processing system. The next step is to test this model in order to examine its dynamic behavior under different circumstances. Before doing that we first have to define the system in its environment as a set of related components:

```use Customers;
use Articles;
use Suppliers;
use Orders;
use PurchaseOrders;
use Invoices;
use Supplies;
use OrderProcessing;
use CouplerOrderProcessing;```

This list of components represents the total system. All the types and operations specified in the interface sections of the components may be used by the user. In this context, the user is the tester of the model.

The model is tested interactively in a dialogue session. External stimuli are simulated by means of operation calls. The behavior of the system will be examined under various conditions. In the dialogues a user can play different roles. In our case study, the user may play one of the following roles:

• Customer
• Supplier
• Manager

The user may act as a customer and see what the reactions of the model are to various kinds of customer orders. The user may also play the role of a supplier by providing new supplies. And finally, the user may play the role of the manager of the company who wants to monitor the order processing activities. For each of those roles we have corresponding operations in the interface section of the OrderProcessing component.

In the following dialogues the role of the user will be indicated. For example, if we are talking about a supplier, we mean: the user acting as a supplier.

We start with a model of a distribution company which has just been founded. The new company starts without any inventory. The manager of the company will ask for an overview of the current state of affairs:

`Overview ( )?`

The system returns with the state of the database:

```{ { },
{ },
{ },
{ } }```

The answer is clear and simple: There are no articles listed, there is no inventory, there have been no invoices sent and there are no outstanding purchase orders. And that is what we may expect from a brand new company.

What will happen if in such a situation a customer tries to order articles from this empty company? Let us assume we first define an order and then ask the company to process that order:

```FirstOrder = Order ( Customer ( "John Smith",
"Iron Street 67, Hammer City"),
Article ("blue ballpoint"), 15);
Process (FirstOrder)?```

The system returns with the message:

```Message ( "To customer: unknown article",
Order:[ Customer = Customer:[ Name = "John Smith";
Address ="Iron Street 67, Hammer City"];
Article = Article:[ Description = "blue ballpoint" ];
Quantity = 15 ] )```

By this message the customer is informed that the requested article from the order is not known to the company. This is what one can expect from a new company.

To solve the problem, the company needs supply of articles. So, the user will, after changing roles, act as a supplier by entering:

```NewSupply ( Supply ( Supplier ("Write Company", "Penstreet 234, Ink City"),
Article ("blue ballpoint"),
3.45, 24 ) )?```

The manager of the company noticed the incoming supply and asks again for an overview:

`Overview ( )?`

The system returns with the current state of the database:

```{ { Article:[ Description = "blue ballpoint"]},
{ Inventory:[ Article = Article:[Description = "blue ballpoint"];
Supplier = Supplier:[Name = "Write Company";
Price = 3.45;
Quantity = 24]},
{ },
{ }}```

The manager observes that blue ballpoints are the only kind of articles in the article list which can be sold, and that there are 24 blue ballpoints in stock with a unit price of 3.45.

What will happen if, in this situation the first customer sends the original order again?

```SecondOrder = FirstOrder;
Process (SecondOrder)?```

The system now returns with the message:

```Message ( "To customer: Articles have been shipped",
Invoice:[Order = Order:[Customer = Customer:[Name = "John Smith";
Hammer City"];
Article = Article:[Description = "blue ballpoint"];
Quantity = 15 ];
Amount = 51.75 ] )```

So, the customer gets the message that the ordered articles have been shipped and he receives the corresponding invoice.

After this transaction the manager consults again the system:

`Overview ( )?`

The system returns with the new state of the database:

```{ { Article:[Description = "blue ballpoint"]},
{ Inventory:[ Article = Article:[ Description ="blue ballpoint"];
Supplier = Supplier:[ Name = "Write Company";
Address = "Penstreet 234, Ink City"];
Price = 3.45;
Quantity = 9]},
{ Invoice:[ Order = Order:[ Customer = Customer:[ Name = "John Smith";
Address = "Iron Street 67, Hammer City"];
Article = Article:[Description = "blue ballpoint"];
Quantity = 15];
Amount = 51.75 ] },
{ }}```

The manager learns that there are 9 blue ballpoints in stock and that an invoice has been sent to customer John Smith.

Let us now assume that the first customer wants another lot of the same ballpoints. He decides to use the original order again:

```ThirdOrder = SecondOrder;
Process (ThirdOrder)?```

The system now returns with two messages:

```Message ("To supplier: Please, send me:",
PurchaseOrder:[ Supplier = Supplier:[ Name = "Write Company";
Address = "Penstreet 234, Ink City"];
Article = Article:[ Description = "blue ballpoint"];
Quantity = 15 ] )
```
```Message ("To customer: delivery is delayed",
Order:[ Customer = Customer:[ Name = "John Smith";
Address = "Iron Street 67, Hammer City"];
Article = Article:[Description = "blue ballpoint"];
Quantity = 15 ] )```

Our domain model reacts in two directions: It sends a purchase order to the supplier and it informs the customer that delivery of the ordered items is delayed.

The manager consults again the system after this transaction:

`Overview ( )?`

The system returns with the new state of the database:

```{ { Article:[ Description = "blue ballpoint"]},
{ Inventory:[ Article = Article:[ Description ="blue ballpoint"];
Supplier = Supplier:[ Name = "Write Company";
Address = "Penstreet 234, Ink City"];
Price = 3.45;
Quantity = 9]},
{ Invoice:[ Order = Order:[ Customer = Customer:[ Name = "John Smith";
Address = "Iron Street 67, Hammer City"];
Article = Article:[Description = "blue ballpoint"];
Quantity = 15];
Amount = 51.75] },
{ PurchaseOrder:[ Supplier = Supplier:[ Name = "Write Company";
Address = "Penstreet 234, Ink City"];
Article = Article:[Description = "blue ballpoint"];
Quantity = 15 ] } }```

The manager checks the number of articles in stock, the list of invoices and the list of outstanding purchase orders. So far, so good.

Let us now assume that the supplier sends the requested articles:

```NewSupply (Supply ( Supplier ("Write Company", "Penstreet 234, Ink City"),
Article ("blue ballpoint"),
3.45, 24 ) )?```

After the new supply has been offered to the system nothing happens! We expected that the new supply would satisfy the demand of the waiting customer and that a corresponding invoice would be sent as we have seen before. Why did it not happen? Examining the company component we discover why our model fails in this situation. There are no provisions in our model for so-called back-orders which should be recorded in case of delayed deliveries and processed after incoming supplies. So, our next version of the model should include the handling of back-orders.

The manager discovers also some flaws in the system after consulting the database:

`Overview ( )?`

The system returns with the new state of the database:

```{ { Article:[ Description = "blue ballpoint"]},
{ Inventory:[ Article = Article:[ Description ="blue ballpoint"];
Supplier = Supplier:[ Name = "Write Company";
Address = "Penstreet 234, Ink City"];
Price = 3.45;
Quantity = 24],
Inventory:[ Article = Article:[ Description ="blue ballpoint"];
Supplier = Supplier:[ Name = "Write Company";
Address = "Penstreet 234, Ink City"];
Price = 3.45;
Quantity = 9]},
{ Invoice:[ Order = Order:[ Customer = Customer:[ Name = "John Smith";
Address = "Iron Street 67, Hammer City"];
Article = Article:[Description = "blue ballpoint"];
Quantity = 15];
Amount = 51.75] },
{ PurchaseOrder:[ Supplier = Supplier:[ Name = "Write Company";
Address = "Penstreet 234, Ink City"];
Article = Article:[Description = "blue ballpoint"];
Quantity = 15 ] } }```

The manager discovers that there are now two inventory descriptors for the same item, while one would be sufficient. He also observes that the satisfied purchase order is still in the database: it should have been removed. Furthermore, there is no concept of minimum stock levels and there are no differences between purchases prices and selling prices. What is also missing in our model are unique identification codes for articles, invoices, customers, suppliers, orders, and so on.

To conclude the discussion about testing our model: we learned a lot about the behavior of the model under different dynamic conditions and we also discovered omissions and mistakes which could be an incentive for an improved version of the domain model.

A revision of the model will be left as an exercise for the reader.

 Part 4: Domain Modeling Chapter 7: Case study: an Order Processing system

 Introduction: Home | Highlights of Elisa | Integrating Different Paradigms | Getting Started with Elisa | Demo's  | What is Domain Orientation | Bibliography | Copyright | News | Contact 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: 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