FIGURE 7.14 The Automaton

supported by means of the T&M approach.

PROBLEM

Tools are used to support human work. When recurring activities have to be done, we call them routing activities or routine work. If such routine activities always produce the same results, we can automate them. If there is only a tool available for the user, then the same tool operations have to be repeated interactively. Such routine work is an ideal candidate for automation. Therefore,

We are looking for a concept to support recurring routine activities with fixed results in an unobstrusive way. The question is what the conditions are and how such routine work could be automated by use of T&M metaphors.

Interrelation of Tools and Materials

Material Design

Domain Service Provider Tool Design

Automaton

Technical Automaton

FIGURE 7.14 The Automaton pattern.

RELATETO

This pattern relates to the design metaphor of an automaton and can be seen as complementary to the conceptual pattern tool design.

SOLUTION

We implement the recurring parts of a job as an automaton. From the user’s view, an automaton encapsulates a specific sequence of work steps without relating to any context to produce a well-defined result, without interruption.

We build an automaton so that it operates similarly to tools on materials, where the input that the automaton requires is limited to a small number of settings or initial interactions.

We refer to such automatons as “small automatons.” They are normally imple-mented to take over tedious routine work and can be used at the user’s discretion within a work environment that includes tools, materials, and containers. If such automatons are suitable for the materials involved, then they can be reconfigured optionally like tools for use within larger work contexts. In this respect, they cover standard cases. For this purpose, a small number of parameters may be set, and the automatons can then run without manual intervention. This limits their use. In a well-ordered work environment, there should be special tools available for special cases, to maintain some flexibility.

Such automatons can be used for various purposes in an application system, with-out destroying the basic character of a workplace designed for autonomous activities.

Automatons play an important role for functional workplaces (see Section 3.6.3). If we want to optimally support well-known sequences of activities, we design an automaton that integrates the components required. This integration is possible in different granu-larities. In a loosely coupled environment, single tools are arranged within the “realm” of an automaton. In this case, the tools maintain their own interaction component, but their interconnection and exchange with materials is controlled by the automaton. In a more strongly integrated environment, the automaton uses the functional component to directly access single tools, itself representing an interaction component. Finally, inde-pendent tools can totally disappear while the automaton uses selected subsets of tools for a specific task, but it directly implements important parts of the domain functionality. This means that the workplace has the character of a control panel.

The higher the integration, the more the automaton of a functional workplace will become a “large automaton,” that is, it actively decides about the sequence of activities involved to complete a well-defined task.

EXAMPLE

In our EMS example, we can see only one domain automaton, which inspects the device park regularly for outdated devices, to then mark them for disposal or upgrading.

This automaton could interact, for example, with the in-tray of the device manager’s mailing system. Then, whenever the device manager activates her electronic desktop, the automaton will check the device inventory for outdated devices in the background.

If appropriate, it will produce a short note and place it in the device manager’s inbox.

All other activities are completed by using tools on specific materials.

Small automatons

Automatons for functional workplaces

DISCUSSION: AUTOMATON VERSUSTOOL

One question we frequently ask is what makes the implemented routine of an automaton different from the algorithm of a tool operation. The answer is nothing, at least from a purely technical viewpoint. In fact, both the routine of an automaton and the algorithm of a tool operation are implemented by instructions, having a well-defined effect on an object or returning a well-defined result.

The most important difference between a tool and an automaton is the use context and the extent of the implemented domain operation, in particular the following:

● Focused on the result to be achieved, a tool is only a means to an end for the user, and its use depends on the work progress and the situation. The tool user has control over each step in the entire work process. In this sense, we expect a software tool not to be “self-operating” but manually directed by a user. For this reason, the tool’s functions should be atomic, from the user’s perspective. Like an elementary action with a manual tool, it wouldn’t make sense for a user to divide a tool’s operation any further. For example, a “sort” operation for a tool that is used to work with business cards is atomic. The user is not interested in the fact that a sorting algorithm has to be executed to implement the steps of that operation.

● In contrast, the use of an automaton means that the control over a defined sequence of activities is passed from a user to an automaton. The user is not interested in actively executing the steps involved in a work process. As long as the standard situation, for which the automaton was built, and the defined result meet the user’s expectations, then the user has no interest in intervening in the process.

In the T&M approach, automatons correspond to our notion of technical processes as an automatism. From the user’s perspective, a computer runs many auto-mated processes to support the expected functionality, where the user is normally not interested in the details. We use this notion of processes in computers to represent domain processes in a suitable way.

In this sense, we have used automatons to encapsulate non–object-oriented com-ponents of a system platform, for example, a relational database (see Section 11.2.5) in early T&M projects. We have used such automatons for two reasons. First, they encap-sulate the concrete protocol and the interface. Second, they implement a domain interpretation of a technical component within the T&M usage model. For example, an automaton for host communication can be used both for the concrete transport of operative data from an object-oriented application system, and to use an appropriate tool to inform users whether or not their connection to the host is established and their data are being transferred.

Similarly, we have encapsulated transport mechanisms over a local area network (LAN) for client-server connection, or to implement a mail system in automatons.

In these cases, rather than representing the automaton itself, the automaton was

“hidden” behind a transport medium, such as an outgoing mailbox or a jointly used registry.

More recently, we have been modeling automatons where an essentially param-eterizable domain result is to be produced. Today, we would think of bundling a set of services or business transactions as domain service providers (see Section 7.10).

Differences between tool and automaton

Encapsulating technical interfaces and components

TRADE-OFFS

The implementation of routines and processes in automatons has proven useful in the following domains:

● To automate tedious human routine activities, where the automaton replaces recurring steps otherwise performed by the use of tools to manipulate materials.

● To control processes at functional workplaces, where the automaton requires minimal user input to produce a specific result using specific materials.

● To map technical processes running relatively independently of the application system in embedded systems. In this case, an automaton represents external technical processes or components that have to be controlled or represented by the application system based on hard or soft real-time constraints.

The automation of tedious routine activities is an important design notion in the development of interactive application systems based on the T&M approach. From the user’s perspective, we first have to identify the routine activities that could be potential can-didates for automation. In this respect, many developers act too quickly once they have identified apparently “tedious” recurring steps. To answer this question on solid ground, we should ensure that the following prerequisites are met for designing a small automaton:

● The activities to be automated are in a well-defined and schematic sequence, and there are only a few alternatives that can be determined in advance.

● The set of activities produces a well-defined result, requiring certain identical or similar materials.

● The process can be completed by an automaton once the materials to be handled and the activities have been selected.

● The result can be seamlessly integrated in larger units of activities.

We have introduced the concept of a large automaton in combination with func-tional workplaces. The autonomy that is characteristic for all our guiding metaphors tells us that we have to observe a certain limit as to how much autonomy such a large automaton should have. The reason is that there will always be a problem when the concrete situation requires a deviation from an automaton’s standard run. For a large automaton, we should also combine the benefits of an optimally supported work process with the flexibility required for special cases. For example, a functional work-place could offer other tools, in addition to an automaton, which would then be used for special cases. Unfortunately, this solution does not always fit the usage model because, for example, the user does not have the skills or possibilities to use these tools.

In that case, we could at least offer some cooperation options to allow a user to del-egate special cases to other workplaces.

There is no general answer to whether or not automatons should have their own interactive user interfaces for resetting or restoring them in case of failure, or whether they are themselves manipulated by adjusting tools. Either solution should be moti-vated by the underlying technology or the application domain.

RATIONALE

Tedious routine activities or routine work should not be supported by a tool. If the sin-gle steps of the tedious routine work can be clearly identified, the user can be supported by means of an automaton.

Automating routine activities

Criteria for the automation of routines

Large automatons

WHATNEXT

Matching design patterns for automatons can be found in the next chapter. Additional conceptual patterns for automatons in the embedded world can be found at the end of this chapter. Also the domain service provider pattern should be considered to take the relationship between automatons and services into account (cf. Figure 7.14).

7.1 0 T H E D O M A I N S E R V I C E P R O V I D E R P AT T E R N

INTENT

Modern technologies support new forms for an organization to present its services and products. In addition, they allow an organization to open up new sales and service channels to better support both customers and suppliers.

PROBLEM

We want to use modern technologies, including the Internet, to realize open systems that integrate various applications and legacy systems within a uniform development and architectural concept.

We need a design concept that encapsulates business logic into units indepen-dent of interaction mechanisms or front ends, making them available for different channels, technologies, and workplace types.

RELATETO

This pattern is related to the concepts discussed in the patterns tool design and automaton. For distributed systems it shows how to extract and encapsulate the business functionality of these two elements (see Figure 7.15).

SOLUTION

We integrate different sales channels and workplace types. We use domain ser-vice providers to offer bundled serser-vices and allow both users and customers and suppliers to easily handle related products and services.

Interrelation of Tools and Materials

Material Design

Domain Service Provider Tool Design

Automaton

FIGURE 7.15