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

4 DOMAIN OPERATIONS

```4.1   Modeling Behavior
4.2   Specifying Domain Operations
4.3   Sources of Operations
4.4   Kinds of Operations
4.4.1 Constructor operations
4.4.2 Accessor operations
4.4.3 Mutator operations
4.5   Mutable and Immutable Domains
4.6   Operations on Basic Domains
4.7   Operations on Composite Domains
4.7.1 Constructor Operations
4.7.2 Accessor Operations
4.7.3 Mutator Operations
4.7.4 Overview of Composite Domain Operations
4.8   Operations on Selection Domains
4.8.1 Accessor Operations
4.8.2 Mutator Operations
4.9    Operations on Enumeration Domains
4.10  Operations on Optional Domains
4.10.1 Constructor Operations
4.10.2 Accessor Operations
4.10.3 Mutator Operations
4.11 Operations on Repetitive Domains
4.11.1 Constructor Operations
4.11.2 Accessor Operations
4.11.3 Mutator Operations
4.12 Operations on Sub-domains
4.13 Operations on Equivalent Domains
4.14 Operations on Predefined Domains
4.15 Combining Different Kinds of Operations
4.16 Guidelines
4.17 Summary
```

The domain definitions of the previous chapter capture the static structure of a system by showing the relationships between different domains. In this chapter we examine the dynamic aspects of a system.

4.1 Modeling Behavior

We learned that concepts are based on other concepts and that domain definitions can be used to express these relationships.

However, concepts do not only have static characteristics, they also represent specific dynamic behavior. For example, if we take the concept of a ball, we are not only talking about properties such as the shape and size of a ball, but also about its behavior if we throw a ball. Behavior describes the actions and reactions over time. Things show specific behavior as a response to external stimulation in a given environment. Kicking a ball in a closed room will result in dynamic behavior which is different from kicking a ball in the open air. External stimulation, such as kicking a ball, is an example of an event which is influencing the behavior. An event is something that happens at a point in time such as a boy is kicking a ball, or a chess player moves the queen.

Because a domain model describes not only the static aspects of a system but also its dynamic characteristics, the behavior of concepts in the problem space should be modeled as well. For that purpose we will use the notion of operations.

Operations are representations in the domain model of actions or reactions of things in the problem space. As we saw, concepts in the problem space are represented by corresponding domain definitions and domain operations. Domain operations are the computer counterparts of concept actions in the problem space. Sets of related operations describe dynamic behaviors under different circumstances. The activation of an operation corresponds to an event in the problem space.

In the preceding chapter we saw that a direct translation of a concept description into a corresponding domain definition is often not feasible. The same applies to the direct translation of concept behavior into corresponding domain operations. Firstly, because the different behaviors of a concept has many manifestations which are difficult to express in domain operations. Secondly, many behaviors are also not relevant for the problem to be solved. Take for instance the concept of a customer; not all the dynamic behaviors of customers can be recorded in a computer, because there are too many. But also, in a computer program we are only interested in a limited number of dynamic aspects of a customer. For example, often we are only interested in what can be sold to a customer and how we get paid, while we are not interested in his voting behavior, or his tax paying behavior.

Translation of concepts behaviors into domain operations means a reduction of information.

As a consequence, only a limited subset of all the dynamic aspects of a concept will be represented by corresponding domain operations.

4.2 Specifying Domain Operations

The operations which should be specified for a domain are determined by the concept behavior we want to model. Let us use as an example the concept of a bank account. Its domain definitions are:

`BankAccount = AccountNumber + Owner + Amount`
```AccountNumber  = subdomain (text)
Owner                  = person
Amount                = real```

Based on these domain definitions we may specify the operations for the BankAccount domain. Therefore we are looking to the concept of bank accounts in the real world. The operations normally related to bank accounts are:

• open a new bank account
• deposit an amount of money
• withdraw an amount of money
• ask for the current balance
• close a bank account

By using these real-world operations on bank accounts we can specify the corresponding domain operations:

`OpenNewBankAccount (AccountNumber, Owner) -> BankAccount;`
`Deposit (BankAccount, Amount)		  -> nothing;`
`Withdraw (BankAccount, Amount)		  -> Amount;`
`Balance (BankAccount) 			  -> Amount;`
`Close (BankAccount)			  -> Amount;`

For domain operations we use the same notational conventions as used for the specifications of functions and operations in Elisa.

Note that for the specifications of the parameters and the results only domain names are used which are elements of the corresponding domain definition for BankAccount.

In this example, the first line contains a specification of the operation OpenNewBankAccount to open a new bank account. In this specification it is assumed that the AccountNumber, and the identification of the Owner client are needed to open a new bank account, but that no initial deposit is required. To make a correct conceptual model such an assumption should be checked against the actual rules of a bank for new bank accounts. The result of an NewBankAccount operation will be a new BankAccount.

After a new bank account has been created the Deposit operation may be used to deposit an Amount of money. The Deposit operation will return nothing.

The third operation is the Withdraw operation, which models the withdrawal of a given amount of money from the bank account.

The Balance operation asks for the actual balance from the bank account.

The Close operation will close the bank account. It returns the remaining money.

This exercise learns us a number of lessons about specifying domain operations:

1. The domain definitions are used as a starting point.

2. Events related to concepts in the real world are used as input for modeling operations.

3. For domain operations the same notation is used as in Elisa for the specification of operations.

4. For the specification of parameters and results of operations, domain names are used.

4.3 Sources of Operations

In our bank account example we discussed already the question: Where do we get the operations from? In general, the input for domain operations are coming from three sources:

1. Behavior related operations.

The first and most important source is based on concept behavior. Therefore we have to answer a number of questions: What behavior do we want to model in our system? What are the external stimuli or events to trigger that behavior? How can we model these events into corresponding operations? The best way is often to look for the concept behavior in the problem space. For example, in the preceding section we looked at the behavior of bank accounts in the real world and discovered behavior related operations.

2. Structure related operations.

A second source for specifying domain operations is the structure of the domain definitions. The structure of a domain suggests a number of operations. Later on, we will discuss in detail how structure related operations are specified.

3. Usage related operations.

A third source of input are the requirements of other domains. As we saw earlier, a domain is often based on other domains. That means that the first domain uses facilities of the other domains and, consequently, operations of the first domain will require the availability of certain operations of the other domains. Take for example the domain of geometrical figures which are made of lines, arcs, circles, ellipses, polygons, and so on. Suppose we want to define a rotation operation for geometrical figures, then this means that also rotation operations should be available for its constituents. So, rotation operations should be specified for lines, arcs, circles, and so on. Those rotation operations are examples of usage related operations.

While behavior related operations and structure related operations are specified early in the conceptual modeling process, usage related operations can, in many cases, only be specified in a later phase. In particular, the requirements for specific usage related operations will only become manifest after the definitions for some other operations are written in following modeling steps. This kind of feedback is an example of where iterations are necessary in the modeling process.

4.4 Kinds of Operations

As will be clear from the bank account example, not all operations are of the same kind. As discovered earlier, there are three common kinds of operations: constructor operations, accessor operations, and mutator operations. The same classification will be used for domain related operations. They have the following properties:

4.4.1 Constructor operations

A constructor operation creates a new data object. For example, OpenNewBankAccount is a constructor operation which creates a new bank account. In our examples, a constructor operation is the first operation of a domain specification. As a convention, we use the domain name as (part of) the operation-name for constructor operations.

4.4.2 Accessor operations

An accessor operation accesses the state of a data object, but it does not alter the state. For example, Balance is an accessor operation; it accesses the state of a bank account, but it does not alter it. Accessor operations may return single values, optional values, or multiple values, depending on the specification.

4.4.3 Mutator operations

A mutator operation alters the state of a data object. For example, the Deposit operation is a mutator operation: it alters the state of a bank account. In general, state transitions are expressed by mutator operations. Mutator operations may return nothing or one or more values as is the case with the Withdraw and Close operations.

4.5 Mutable and Immutable Domains

Domains may be divided into mutable and immutable domains. The difference is related to the state handling of the data objects. States of data objects belonging to mutable domains can be changed; states of data objects belonging to immutable domains cannot be altered.

Data objects of mutable domains are used to represent the current state of their real life counterparts. For example, depositing money on a bank account will change the state of the bank account. Consequently, the state of the corresponding data object, representing the bank account, will also be changed after the activation of the Deposit operation. The Deposit operation is an example of a mutator operation which alters the state of the BankAccount.

For immutable domains there are no mutator operations defined. That means that the state of the data objects cannot be altered. As a consequence, after their creation, data objects of immutable domains are never changed. See also the discussion in Chapter 10 of the Language Description, Section 10.8, about "Mutable and Immutable Objects". In that section examples of mutable and immutable objects have been given. In this chapter we are extending the concept of mutability from objects to domains.

4.6 Operations on Basic Domains

In the preceding chapter we discussed how domains are defined and how basic domain definitions can be derived from more complex domain definitions. In the following sections we will examine how operations can be defined for the different kinds of basic domain definitions.

As stated earlier, the operations for a particular domain are depending on the concept behavior we want to model, on the structure of the domain definition, and on the requirements of other domains.

The specifications of behavior related operations are very much dependent on the kind of the concept we like to model. For example, the operations of a bank account are very different from the operations associated with geometrical shapes. There are no general rules for deriving behavior related operations. The nature of the concept itself determines the operations.

The specifications of usage related operations are dependent on the requirements of other domains. After the operations for the other domains have been defined, the usage related operations can be specified.

The specifications of structure related operations are determined by the structure of the domain definitions. In the following sections we will examine how to use the structure of basic domain definitions to specify associated operations.

Fortunately, it turns out that for many domains, structure related operations are also satisfying requirements for behavior related operations, as well as for usage related operations.

4.7 Operations on Composite Domains

A composite domain definition has the following structure:

P = A + B + C + ...

where P is the name of a new domain and the domain elements A, B, C, ... are names of other domains. In this section we assume that A, B, C, ... are simple domain names; later on we will discuss other domain elements such as optional domains and repetitive domains.

Based on the structure of this composite domain definition we can specify:

• Constructor Operations
• Accessor Operations
• Mutator Operations

4.7.1 Constructor Operations

A constructor operation creates a new data object. That data object will have as many elements as there are domain elements in the domain definition. The values of all those elements may be supplied by the constructor operation. In that case the following constructor specification can be used:

P (A, B, C, ...) -> P;

In the constructor specification we use the domain name P as the operation name and also as the result name (naming conventions in Elisa make sure that there is no ambiguity). The names of all the domain elements are used to specify the parameters of the constructor operation.

However, it is not always necessary that all domain elements are supplied by the constructor operation. Depending on the domain, some elements may be initialized with default values; in that case only a subset of domain elements need to be supplied by the constructor. Take, for example, the constructor operation for BankAccount; the domain definition has four elements, but the constructor operation supplies only three. In such a situation only a limited number of domain elements has to be used in the constructor operation, such as:

P (A, B, ...) -> P;

For some domains it may be worthwhile to specify more than one constructor operation. Take, for example, the domain of points in three-dimensional space:

Point = X + Y + Z

The elements X, Y, and Z are domain names of the corresponding co-ordinates. According to the rules, a constructor operation for the composite Point domain could be specified as follows:

Point (X, Y, Z) -> Point;

However, based on the same domain definition we can specify, in addition, a constructor operation for two-dimensional points:

Point (X, Y) -> Point;

With this specification it is assumed that the Z domain will be represented by a default value such as zero.

4.7.2 Accessor Operations

For a composite domain definition such as:

P = A + B + C + ...

the specifications of basic accessor operations has the following form:

`A (P) -> A;`
`B (P) -> B;`
`C (P) -> C;`
`        .`
`        .`

If we use as an example our previous example:

Point = X + Y + Z

then the corresponding accessor operations are:

X (Point) -> X;

Y (Point) -> Y;

Z (Point) -> Z;

From the domain definition:

Person = Name + Address + Birthdate

the following accessor operations can be derived:

Name (Person) -> Name;

Birthdate (Person) -> Birthdate;

Notice that we are using the same names as used in the domain definition. No other names are required.

4.7.3 Mutator Operations

Mutator operations may only be defined for mutable domains. For immutable domains no mutator operations are allowed. If P is a mutable domain and it has the following structure:

P = A + B + C + ...

then a set of basic mutator operations can be specified:

`change_A (P, A) -> nothing;`
`change_B (P, B) -> nothing;`
`change_C (P, C) -> nothing;`
`                       .`
`                       .`

However, even for mutable domains, not all the elements may be changed. Some elements have to keep their initial values which may not altered. For example, a social security number has a fixed relationship with a person and may probably not be changed. It depends on the nature of a domain element, if a corresponding mutator operation should be specified.

If our previous example of Person represents a mutable domain then the three basic mutator operations are:

change_Name (Person, Name) -> nothing;

change_Birthdate (Person, Birthdate) -> nothing;

We may introduce in these specifications some additional clarification as, for example:

change_Name (Person, NewName = Name) -> nothing;

change_Birthdate (Person, NewBirthdate = Birthdate) -> nothing;

NewName, NewAddress, and NewBirthdate have no other meaning than to serve as a clarification for the reader as we already knew from Elisa specifications. Consequently, our general scheme for mutator operations could also have been written as:

`change_A (P, new_A = A) -> nothing;`
`change_B (P, new_B = B) -> nothing;`
`change_C (P, new_C = C) -> nothing;`
`                              .`
`                              .`

However, in the following we will stick to the initial scheme for mutator operations, because in mutator operations not always new values are introduced. Sometimes existing values are changed. See, as an example the UpdateSalary operation discussed in Section 9.4, where changing salaries are modeled.

4.7.4 Overview of Composite Domain Operations

For the composite domain definition of:

P = A + B + C + ...

an overview of the structure related operations is given in Figure 4-1.

`<< constructor operations: >>`
`P (A, B, ...) -> P;`
`P (A, B, C, ...) -> P;`

`<< accessor operations: >>`
`A (P) -> A;`
`B (P) -> B;`
`C (P) -> C;`
`         .`
`         .`
`<< mutator operations: >>`
`change_A (P, A) -> nothing;`
`change_B (P, B) -> nothing;`
`change_C (P, C) -> nothing;`
`           .`
`           .`

Figure 4-1: Overview of Composite Domain Operations

Let us apply this schema to the domain definition for Family:

Family = Father + Mother + Children

Based on this domain definition and using the schema of Figure 4-1 we can equate the names used in the example to the names used in the schema:

P = Family

A = Father

B = Mother

C = Children

With these equations the following operations can be derived:

<< constructor operations: >>

Family (Father, Mother) -> Family;

Family (Father, Mother, Children) -> Family;

<< accessor operations: >>

Father (Family) -> Father;

Mother (Family) -> Mother;

Children (Family) -> Family;

<< mutator operations: >>

change_Father (Family, Father) -> nothing;

change_Mother (Family, Mother) -> nothing;

change_Children (Family, Children) -> nothing;

In general, all operations of a composite domain definition are expressed in terms of the element domains.

Exercises:

• 4.1 Specify structure related operations for the BankAccount domain of Section 4.2.
• 4.2 Specify structure related operations for the following domain:

name = firstname + familyname

• 4.3 Specify structure related operations for the following domain:

Country = CountryName + Capital + Area + Population

• 4.4 Make a domain definition for employees. An employee may be hired, promoted, and fired. A promotion includes a raise in salary. Specify the corresponding domain operations.

4.8 Operations on Selection Domains

A selection domain definition has the following structure:

S = P | Q | R | ...

where S is the name of a new domain and the domain elements P, Q, R, ... are names of other domains.

For selection domains we may specify the following kinds of basic operations:

• Accessor Operations
• Mutator Operations

Constructor operations cannot be defined for selection domains!

4.8.1 Accessor Operations

For a selection domain definition such as:

S = P | Q | R | ...

the specifications of basic accessor operations has the following form:

A (S) -> A;

B (S) -> B;

C (S) -> C;

.

The operations A, B, C, ..., are behavior related operations or usage related operations. No structure related operations can be defined for selection domains. Operations specified for selection domains will require similar operations for the alternative member domains. That means, for instance, that the operation:

A (S) -> A;

also should be defined for the P, Q, R, ... domains:

A (P) -> A;

A (Q) -> A;

A (R) -> A;

Let us use, as an example, the domain definition for customer, as used earlier:

customer = person | organization

and let us assume that we want to specify the following accessor operations for customers:

name (customer) -> name;

telephone (customer) -> telephone;

then the name, address, and telephone operations should also be defined for persons and organizations.

In general, operations specified for a selection domain will require corresponding operations for the alternative domains. They are examples of usage related operations.

4.8.2 Mutator Operations

If a selection domain is a mutable domain then mutator operations may be specified. If S is a mutable domain and it is defined as follows:

S = P | Q | R | ...

then a set of basic mutator operations can be specified:

change_A (S, A) -> optional (boolean);

change_B (S, B) -> optional (boolean);

change_C (S, C) -> optional (boolean);

.

In contrast to mutator operations for composite domains, here we use the optional (boolean) result specification. The reason will become clear after the discussion in Section 5.3, "Implementation of Selection Domains".

The operations change_A, change_B, change_C, ..., are behavior related operations or usage related operations.

For mutator operations the same rules apply as for accessor operations of selection domains: operations specified for a selection domain will require corresponding operations for the alternative domains. That means that if a mutator operation is specified for a selection domain, the selection domain and its alternatives are mutable domains.

Let us again use, as an example, the domain definition for customer:

customer = person | organization

and let us assume that we want to specify the following mutator operations for customers:

change_name (customer, name) -> optional (boolean);

change_telephone (customer, telephone) -> optional (boolean);

then the change_name, change_address, and change_telephone operations should also be defined for persons and organizations.

Exercise:

• 4.5 Specify the same operations as defined for customers also for organization:

organization = Government | Industry | University

4.9 Operations on Enumeration Domains

No specific domain operations need to be specified for enumeration domains.

4.10 Operations on Optional Domains

Optional domains are often elements of composite domain definitions as illustrated by:

P = A + [B] + C + ...

where P is the name of a new domain and A, B, C, ... are names of other domains. [B] represents an optional domain.

Based on this structure we can specify:

• Constructor Operations
• Accessor Operations
• Mutator Operations

4.10.1 Constructor Operations

As discussed for composite domains, constructor operations may supply the values for all domain elements, or for a subset of it. If there is one optional domain in a composite domain then two constructor operations are possible. in case of an optional domain there are two versions self-evident. The first version assumes that no initial value for the optional domain [B] is required:

P (A, C, ...) -> P;

The second version provides an initial value for [B]:

P (A, B, C, ...) -> P;

Based on an earlier example, let us assume that the name of a person may or may not include a middle name. This is specified in the following way:

name = firstname + [middlename] + familyname

There are now two possible constructor operations. The first one is:

name (firstname, familyname) -> familyname;

which is used in case a person has no middle name; and a second one:

name (firstname, middlename, familyname) -> familyname;

which is called if a person has a middle name.

4.10.2 Accessor Operations

For domain definitions with optional domains, such as:

P = A + [B] + C + ...

there are several ways to specify basic accessor operations for an optional domain depending on the representation of optional domains.

As discussed in the previous chapter, an optional domain such as [B], has the following meaning:

[B] = B | null

This may be interpreted as: the optional domain [B] consists of all the values of B or the null value. In other words, if B is absent, a null value is present.

By using that interpretation, we may specify an accessor operation for an optional domain element in the same way as we did for other domains of a composite domain:

B (P) -> B;

This operation will return a value of the B domain or the null value.

However, the disadvantage of this operation is that the user should be aware of the fact that the result may be a null value. That can be avoided by slightly modifying the operation specification into:

B (P) -> optional (B);

This operation will only return a value of the B domain if there is one.

Another kind of accessor operation which may be sometimes useful, is an operation which asks if a domain value exists:

exists_B (P) -> boolean;

This operation will return false in case of a null value.

Applying this to the optional domain of middlename in the example:

name = firstname + [middlename] + familyname

we can specify the following accessor operations:

middlename (name) -> middlename;

or:

middlename (name) -> optional (middlename);

and:

exists_middlename (name) -> boolean;

Each operation has its own set of characteristics.

4.10.3 Mutator Operations

For domain definitions with optional domains, such as:

P = A + [B] + C + ...

mutator operations may be specified if P is a mutable domain and [B] may be altered.

One of the mutator operations is the same as for non-optional domains:

change_B (P, B) -> nothing;

This operation will change the value of B.

Another kind of mutator operation which may be useful, is an operation which will remove a domain value:

remove_B(P) -> nothing;

This operation will remove the B value. The value will be replaced by a null value. Nothing will be returned.

Applying this to the optional domain of middlename in the example:

name = firstname + [middlename] + familyname

we can specify two mutator operations:

change_middlename (name, middlename) -> nothing;

remove_middlename (name) -> nothing;

depending on the requirements.

4.11 Operations on Repetitive Domains

Repetitive domains are often elements of composite domain definitions as illustrated by:

P = A + B + {C} + ...

where P is the name of a new domain and A, B, C, ... are other domain elements. {C} represents a repetitive domain.

Based on this structure we can specify:

• Constructor Operations
• Accessor Operations
• Mutator Operations

4.11.1 Constructor Operations

As discussed for composite domains, constructor operations may be used to supply all the values of the domain elements. However, for repetitive domains this is often not a good approach, because the values of a repetitive domain are in many situations not known in advance. Their number may vary dynamically. Therefore it is often better to define specific operations to add new values to a repetitive domain and to remove existing values from it. These operations will be discussed under the heading of mutator operations.

As a consequence, we will not include values of repetitive domains in a constructor operation. Based on the domain definition we will use the following specification for the constructor operation:

P (A, B, ...) -> P;

where C is not included.

Based on an earlier example, let us assume that a family consists of a father, a mother and a number of children. This can be defined as follows:

Family = Father + Mother + {Child}

Note that this domain definition is different from the one used in Section 4.7.4. Under the assumption that a family starts with no children, the constructor operation for a family is:

Family (Father, Mother) -> Family;

4.11.2 Accessor Operations

For domain definitions with repetitive domains, such as:

P = A + B + {C} + ...

two kinds of basic accessor operations are recognized: one to return all the elements of the repetitive domain and another to return a specific element.

To return all the elements of the repetitive domain the following basic accessor operation can be specified:

C's (P) -> multi (C);

This operation will return all the values of {C}. By convention, we will use as name for the operation the plural of C, indicated as C's.

Operations on repetitive domains may also operate on specific elements. Those operations assume that each element can be identified separately. To designate a specific element, we will assume that with each element an identifier, called ID, is associated which identifies the element. So, for the repetitive domain {C} each C has an identifier C_ID.

The operation which will return a specific element from the repetitive domain is given by:

C (P, C_ID) -> optional (C);

which will return a C from P if the specified C belongs to {C}. The C which should be returned is identified by C_ID.

By applying this to our example of:

Family = Father + Mother + {Child}

the accessor operation to return all the children is:

Children (Family) -> multi (Child);

The accessor operation which will return a specific child is:

Child (Family, Name) -> optional(Child);

For this operation, it is assumed that a child is identified by its name.

4.11.3 Mutator Operations

For domain definitions with repetitive domains, such as:

P = A + B + {C} + ...

two kinds of mutator operations are required: one for adding new values to a repetitive domain and another to remove existing values from it.

To add a value to a repetitive domain we will use the following specification:

which will add a new C to P.

To remove a value from a repetitive domain we will use the specification:

remove_C(P, C_ID) -> optional (C);

which will remove C from P if the specified C belongs to {C}. The C which should be removed is identified by C_ID. The removed C will be returned.

There are also other variations of the remove operation possible, such as:

remove_C (P, C_ID) -> nothing;

This operation will remove the first C, identified by C_ID, if C exists. It returns nothing.

Another variation is: remove all C's, identified by C_ID, and return them:

remove_C (P, C_ID) -> multi (C);

This operation will remove all C's, identified by C_ID. All removed C's will be returned.

As an illustration of mutator operations for repetitive domains we may apply the rules to our example of:

Family = Father + Mother + {Child}

We can define operations for adding and removing children from the family.

The add operation may be specified as:

Again assuming that a child is identified by its name we can specify the following remove operation:

remove_Child (Family, Name) -> optional (Child);

Exercises:

• 4.6 Define structure related operations for:

Department = Name + Manager + {Employee}

• 4.7 Define structure related operations for:

Articles = {Article}

4.12 Operations on Sub-domains

Structure related operations cannot be specified for sub-domains.

In some cases, behavior related operations may be useful for sub-domains. For instance, it is sometimes convenient to define sub-domains for money, such as dollars, pounds and guilders, or for units of physical dimensions, such as length, weight, and time.

Let us use as an example the following domain definitions:

meter = subdomain (length)

yard = subdomain (length)

length = subdomain (real)

We may now specify behavior related operations such as:

`meter + meter -> meter;`
`meter - meter -> meter;`
`yard + yard -> yard;`
`yard - yard -> yard;`
`meter (yard) -> meter;    << conversion from yard to meter >>`
`yard (meter) -> yard;      << conversion from meter to yard >>`

4.13 Operations on Equivalent Domains

Structure related operations cannot be specified for equivalent domains.

In general, there is no need to define specific operations for domains which are declared to be equivalent to an already existing domain, because all operations defined for the existing domain are also valid for the newly declared domain. For example, if a client is another name for customer as expressed by the following domain definition:

client = customer

then all operations defined for customer are also defined for client.

4.14 Operations on Predefined Domains

In general, there is no need to define additional domain operations for predefined domains, because for each predefined domain there are already operations defined in the Elisa language which are sufficient for normal use.

4.15 Combining Different Kinds of Operations

In the previous sections we mainly discussed structure related operations. However, in many situations structure related operations have to be combined with behavior related operations and usage related operations.

Let us use, for example, the operations defined on a bank account. The behavior related operations are:

OpenNewBankAccount (AccountNumber, Owner) -> BankAccount;

Deposit (BankAccount, Amount) -> nothing;

Withdraw (BankAccount, Amount) -> Amount;

Balance (BankAccount) -> Amount;

Close (BankAccount) -> Amount;

Based on the domain definition:

BankAccount = AccountNumber + Owner + Amount

the following structure related operations can be derived:

<< constructor operation: >>

BankAccount (AccountNumber, Owner) -> BankAccount;

<< accessor operations: >>

AccountNumber (BankAccount) -> AccountNumber;

Owner (BankAccount) -> Owner;

Amount (BankAccount) -> Amount;

<< mutator operations: >>

change_AccountNumber (BankAccount, AccountNumber) -> nothing;

change_Owner (BankAccount, Owner) -> nothing;

change_Amount (BankAccount, Amount) -> nothing;

Our initial thoughts may be to combine the two sets of operations. However, before we may do that, it is better to examine both sets for incompatibilities. For example, in the behavior related set of operations, the amount of money on a bank account is changed by the Deposit and Withdraw operations. In the second set, this is done by the change_Amount operation. We may assume that the Deposit and Withdraw as behavior representing operations will take care of the necessary security measures, as the real bank operations will do. But these measures cannot be expected from the change_Amount operation. The reason is that structure related operations are operating on individual domain elements, while, in general, behavior related operations may take more domain elements into account before the operation will be carried out. For example, a Withdraw operation may first check the requested amount against the actual amount and the credit limit before the requested amount is withdrawn.

In general, structure related operations are often of a lower level than behavior related operations. In particular, structure related mutator operations provide the opportunity to change data without proper safeguards and should therefore only be introduced if there are no dangers of corrupting data. In our example, the change_Amount operation bypasses all checks and is for that reason unacceptable.

There are two other structure related mutator operations which should be considered: the change_AccountNumber and the change_Owner operations. Both operations depend on the policies of the bank. Is it allowed to change the account number or the owner of an existing bank account? If, for consistency reasons, the bank decides that this is not allowed, the operations are not included in the final list of operations. In the following we will assume that the account number may not be changed, but that the owner of a bank account may be changed.

The three structure related accessor operations should also be examined. The operations to obtain the AccountNumber and the Owner of a bank account are useful operations. However, the Amount operation has the same function as the Balance operation and can therefore be discarded.

The OpenNewBankAccount operation and the constructor operation BankAccount are providing the same function, so, we will drop OpenNewBankAccount operation.

Based on these decisions, the combined list of accepted operations can be made (see Figure 4-2).

`		<< constructor operation: >>`
`BankAccount (AccountNumber, Owner) -> BankAccount;`
`		<< accessor operations: >>`
`AccountNumber (BankAccount) -> AccountNumber;`
`Owner (BankAccount) -> Owner;`
`		<< mutator operation: >>`
`change_Owner (BankAccount, Owner) -> nothing;`
`		<< behavior related operations: >>`
`Deposit (BankAccount, Amount) -> nothing;`
`Withdraw (BankAccount, Amount) -> Amount;`
`Balance (BankAccount) -> Amount;`
`Close (BankAccount) -> Amount`

Figure 4-2: Example of a combined set of operations

In general, structure related operations, behavior related operations, and usage related operations must be combined into a coherent set of operations without duplications or loopholes.

4.16 Guidelines

The third step of the conceptual modeling process is to specify domain operations based on the basic domain definitions defined in step 2.

For every basic domain definition try to answer the following questions:

1. Is the domain a mutable or an immutable domain?

2. What are the behavior related operations which are required by the concept in the problem space?

3. Which structure related operations can be derived from the domain definition?

4. Make a tentative list of usage related operations.

5. Combine the different kinds of operations into one set of domain operations. Make also a verbal description of each operation which describes its purpose and actions.

Later on, other operations may be added to the list.

4.17 Summary

• Domain definitions capture the static structure of a system by showing the relationships between different domains. Domain operations are specifying the dynamic aspects of a system. Together they form the domain specifications.
• Domain operations are the computer counterparts of concept actions in the problem space. Sets of related operations describe dynamic behaviors under different circumstances. The activation of an operation corresponds to an event in the problem space.
• Translation of concepts behaviors into domain operations means a reduction of information. Only a limited subset of all the dynamic aspects of a concept will be represented by corresponding domain operations.
• In general, 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.
• There are three kinds of operations are: constructor operations, accessor operations, and mutator operations.
• Domains may be divided into mutable and immutable domains. States of data objects belonging to mutable domains can be changed; states of data objects belonging to immutable domains cannot be altered.
• We examined for the different kinds of basic domains the associated domain operations based on domain structure.
• Structure related operations, behavior related operations, and usage related operations must be combined into one coherent set of operations.
• As a result of this modeling step a list of operations for each domain definition will be used as input for the following step.

 Part 4: Domain Modeling Chapter 4: Domain Operations

 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