FIGURE 7.11 Containers at

contents

Polymorphic containers

Order principles

Toolbox

EMS-Registrar TrashCan

Material Templates

SWT-RoomMap

DeviceCheckerCenter

Value-Definer

FIGURE 7.11 Containers at the Device Manager workplace.

this risk, we explicitly build orders in our domain containers. This means that a container knows its order principle and ensures that it is observed. Similarly, objects are stored in their correct place when they are added and this place is maintained for other altering operations as well.

In our discussion of design metaphors for container in Section 3.5.18, we already mentioned that domain containers have a management function. In conventional sys-tems, the user of a container manages the objects stored in that container by taking explicit actions, such as manually inserting documents at the right place or keeping index lists. We could implement this expensive and error-prone manual management work as additional internal features for domain containers. This would include tables of contents, consistency checks, and operations on collections. A good example would be a shares portfolio as a bank-specific container that calculates the portfolio value based on current stock rates.

Taking this management idea a step further and combining it with consistency control, we could think of specialized containers such as a credit application file.

Although the content of such a container is heterogeneous, it is defined within narrow limits. We often model such containers using pockets or tabs to clearly show in the usage model that this container manages a specific combination of documents. This definition of contents and internal consistencies allows us to answer a number of ques-tions about the contents on the container level. For example, a credit application file can provide information about the credit contract state, that is, whether or not sol-vency has been checked and the application has been granted.

A container is also a useful metaphor where requested materials have to be col-lected and forwarded for further processing. This is often the case in database applica-tions. For example, a user has to collect a number of customers that meet a specific selection criterion. A conventional database query outputs a set of results. In the object-oriented world, there is no such thing as a “set of results.” Instead, it has to be represented in a domain-specific way. It is often useful to implement a set of results as a collection of similar materials in a known container, such as a folder. This raises another question: How can we model non–object-oriented databases in T&M systems?

If we want to use such a database essentially to store objects, we could use an automa-ton or a service provider for encapsulation (see Section 11.2).

So far, we have just touched upon the transport aspect. In fact, it plays a subor-dinate role in a single workplace. On the other hand, it is convenient to move around an entire material collection in a container. The transport aspect comes into play if we want to move entire collections between different rooms within one envi-ronment or between different envienvi-ronments. In this case, a container could be the

“natural” transport medium, simulating the way we move folders or containers in the real world (see Sections 10.3.2). These transport containers could also be useful to allow coordination in a collaborative work environment. When you put a file onto your colleague’s desk, then this normally indicates what has to be done and who is in charge.

BACKGROUND: CONTAINERS

From the conceptual and constructive perspectives, you could think of a container as a material. In fact, we generally assume that most complex tools operate on one or more containers to facilitate users to select the desired materials.

Material

On the other hand, containers occupy a special position versus “normal” materials, because containers are always designed to contain other materials, as well as to organ-ize these materials by calling operations on these materials. In real-world projects, this has often led to the problem that containers have been modeled as a kind of tool with corresponding interfaces and an observer mechanism (see Section 8.11.6).

In workplace systems developed by the T&M approach, domain containers (e.g., a collection of bank accounts) assume management and aggregate functions, such as managing account lists or summing daily sales figures. This means that they have moved away from the classical data structures and collection classes.

From the developer’s view, we have to distinguish containers motivated by the application domain from the technical data structures. For developers, data structures are typical software containers that they handle all the time when programming.

Therefore, from the developer’s view, containers like lists, trees, and hash tables are

“domain-specific” containers used to manage data. In traditional software engineering, data structures have been specified as abstract data types, but they are also thought of as imperative composite data types of a programming language. This situation changed when object-oriented languages introduced active technical containers, offering their own navigational concept (with operations like first and next) by the use of so-called markers, in addition to encapsulated states by means or access operations.

These technical containers are called collection classes and were used in many object-oriented applications.

In contrast, the T&M approach distinguishes technical containers from domain containers, the latter being independent work objects. For domain containers, we iden-tify the interactions motivated by the tasks of the application domain. In addition, we design variants of domain containers, where we are not limited to a generic concept of folders and files.

There is another reason why we have to explicitly model containers. In object-oriented languages, a class doesn’t automatically give you a collection of all of its instances. In this respect, object-oriented languages are totally different from a rela-tional database. In fact, one of the main features of the relarela-tional model is that you can use a relation, implemented as a table, to also address all pertaining tuples or records.

This is something we hardly ever need in an application-oriented model. Instead, we often want to store the different instances of a class in different locations, because this lets us elegantly model different stacks for closed and pending cases or applications and represent them in a usage model.

RATIONALE

Containers are an important concept of our daily work. We often have to deal with a number of materials. We keep them together, order them in separate folders, or move around briefcases containing materials. Therefore, domain containers became an elementary part of application-oriented software development.

WHATNEXT

In addition to the container pattern, which might be regarded as a special kind of material, another special kind of materials may be found in forms, as discussed in the next section. Also, Chapter 8.11 presents the next step in implementing containers using design pattern domain container for this purpose.

Containers and data structures

Domain-specific interactions and specializations for containers

7. 8 T H E F O R M P AT T E R N

INTENT

Paper forms and electronic forms play an important role in many application domains, particularly in office environments. In the T&M approach, these forms are a special kind of material.

PROBLEM

When analyzing an application domain, we often find materials for which it is rather difficult to identify an individual domain-specific usage. We normally find that users fill out the fields of a form and read its contents, for example, customer information forms, purchase order forms, or application forms. An attempt to model such objects often ends with a number of generic operations to set and get data. It seems, therefore, to be superfluous to design and implement them as individual materials. In addition to this generic domain-specific usage, forms are also characterized by their layout, which is usually distinguished between fixed and editable fields.

When designing appropriate tools for these forms, we also often find that their domain operations are rather limited or nonexisting, because we look primarily for an electronic version of a pen. In this attempt, we often end up with editors that can be used to set and get information more or less generically. Therefore,

How can we integrate the concept of paper forms into the overall modeling approach of application orientation? Is it sufficient to model forms as materials or do they show characteristics of their own?

RELATETO

Forms are a special kind of material. Therefore, they are closely related to the conceptual pattern of material design as well as the material design metaphor (see Figure 7.12).

SOLUTION

We deal with forms as independent conceptual patterns, because they represent special materials across all development phases, from design to construction.

Interrelation of Tools and Materials

Material Design

Form

FIGURE 7.12