FIGURE 7.3 Material design

Design Interrelation of Tools

and Materials

Domain Service Provider

Container Form Tool Design

FIGURE 7.3 Material design.

simply named materials, using names familiar in the application domain. In addition, we defined general concepts in the context of our application domain. These existing materials and general concepts form the basis for designing materials on another level—the material classes.

RELATETO

The pattern material design is related to the conceptual pattern interrelation between tools and materials and the tool design metaphor (Figure 7.3).

SOLUTION

The T&M approach does not put the presentation and manipulation of materials in the foreground, because they are normally displayed and handled by a tool or an automaton within the usage model. Therefore,

We can focus on the domain functionality when designing materials. We identify the relevant functionality by looking at the various tasks, we work with the respective materials.

For each existing material, we have to check the actual contribution it makes in completing tasks. In many cases, we will find that objects are used solely because they are required by existing (automated or manual) data processing forms. We think that this is the only explanation for why there are so many control lists and change request forms. Such things can often be removed by application-oriented software support.

One of the most important ideas behind the T&M approach is to add abstract concepts, represented as materials, to the system, in addition to the obvious things found in the application domain.

We briefly mentioned several examples of such concepts, such as bank accounts or credits, in previous sections. Note that these notions do not exist as concrete objects.

You will not find an account in a bank as a “tangible thing.” What you will find at the workplace are forms, for example a form to open an account or make a money transfer or deposit, and representations of these forms on the screen. However, bank employees have to handle accounts, and they have clear notions about these accounts, depend-ing on the department and the workplace. This suggests that the account as an abstract concept should be modeled as an independent material rather than as a collection of related objects and representations.

Materials offer more than certain domain interactions, which can be modeled by operations of a class. Materials also represent a conceptual unit, encapsulated in the design. This means that, in our design, we also define the domain integrity of a material to ensure that it will be retained. For this purpose, we encapsulate the internal states of a material class, that is, we hide it from direct access, as opposed to those domain states that are externally visible. Depending on these material states, we can define reliable interactions. Next, we define the protocol for a material class, which ensures the inter-nal domain consistency of a material. We can use state charts (see Section 13.9.5) in this modeling process. The internal consistency is ensured by assertions for all state-changing operations, based on the design-by-contract model (see Section 2.3).

EXAMPLE

In the design of our EMS example, we first analyze the tasks at hand and how they are completed. We have already seen that the device manager handles several materials,

Concentrating

including room plans, employees lists, and device order forms. We can elaborate a domain description of how these materials should be handled. We have several concepts, such as, room, device, employee, and room occupancy. We also have a pretty clear picture of the work situation and the steps involved: the room plan is edited; employees or devices are moved to different rooms; new devices are purchased; and the device statistics is evaluated.

From all the above, we can derive clear indications for our material design. We could adopt the existing materials and their domain interactions in our design. For example, we could model a class, Employees, to accommodate all information relat-ing to a team member’s employment contract. It also appears meanrelat-ingful to reflect about implementing the room, device, and room plan concepts in software.

At this point, we will probably think about a way to represent employees in the room plan, where extensive information about the employment contract is not required. One solution would represent employees by business cards in the room plan.

This would reflect a familiar notion for the set of information we want to find about an employee in the room plan.

This solution could be used to work out several domain interactions. For example, the device manager could look at a business card to see whether or not this employee is authorized to occupy a separate room, or whether he or she should share a room with other employees, depending on their positions. In the past, the device manager had to run these checks manually, but we can now use the potential of software and transfer this background check to the material in our design. As an object, the business card can tell us whether or not an employee is eligible for a separate room. This means that we develop domain interactions for a material beyond the material’s current properties.

Similarly, we could discuss another class, Device, and a device identification card to represent a device object in a room plan.

TRADE-OFFS

We cannot look at each of the materials of an application system in isolation. There are essentially two different relationships between materials: a contains relationship and a use relationship (see Section 2.1.18).

For example, a room in the room plan of our EMS example can either contain or use devices. Whether a relationship is a contains or use relationship can be seen only from the domain-specific context. To facilitate this issue, it is often useful to ask whether or not a material would make sense both with and without its “neighboring”

material in the application system. As far as our EMS example is concerned, we can say that devices can also be meaningfully handled even when they are not allocated to a room. For this reason, we model rooms that use devices.

We have said that we can handle a material only provided that we have a tool (or automaton). Nevertheless, we have to bear in mind that a material should also be suit-able for interaction. To support this aspect, the material should offer probing opera-tions for all properties that users would like to see in that material. This means that we have to include operations that make a material suitable for interactive handling and presentation in our design. We conclude that the close relation between conventional materials and tools also applies to software materials.

On the other hand, even software materials are independent of tools in comput-ers. The domain interactions are the stable elements in our modeling effort, and we classify and group materials based on the similarity of their interactions.

Material and interaction

The fact that we have primarily discussed a material’s interactions does not mean that the material state is negligible from the domain view. Structural information is required to be able to implement material states in the first place. We can combine materials from other materials or let them use other materials. However, the state of a material is eventually based on values. Each probing of a material returns state infor-mation, determined on the basis of the material’s own values. For design purposes, the internal state should be separated from the externally represented state information in our implementation. This information-hiding principle is primarily implemented by the use of domain values (see Section 2.6.5).

DISCUSSION: GENERICOPERATIONS

Each change to a material is effected by changing structural information. We saw in Section 2.1.10 that a class can define generic operations, which can be used by the operations of that class to access the internal structure of an instance of that class. Although this is often intuitive and supported by different development envi-ronments, when modeling materials, we pay particular attention to ensure that these generic operations are not made public to represent the domain interface of a material.

Many inexperienced developers tend to design materials as pure value collec-tions. Occasionally, this indicates that the domain was not well understood, particu-larly if material designs are developed starting from a user interface. Such designs often resemble interactive tools from GUI elements, which present material informa-tion and make the material manipulable. What often happens in such designs is that the entire domain functionality and the integrity of materials reside in a tool and its GUI elements (widgets), while the materials themselves degenerate to containers of value lists.

Admittedly, modeling materials based on domain interactions at the beginning of a project is difficult in many cases. These conventional materials are often paper forms, consisting of a series of fields used to write or read values. Section 7.8 describes such forms in detail. Our experience has shown that forms-based materials often develop into material during the course of the development process, that is, when we add domain interactions to their interfaces. For this reason, we should not think of materials and forms as two totally different things.

RATIONALE

Designing materials for the application system is one of the central activities of developing an application-oriented system. Materials form the basis for the entire system. Therefore, materials should be designed in a careful and conceptually mean-ingful way.

WHATNEXT

Closely related to materials are the tools to manipulate them in the application system (see Figure 7.3). Therefore the following tool design pattern should be read next.

Managing large collections of materials is a task that we usually allocate to a domain service provider, as described in Section 7.10.

Special material conceptual patterns are forms and containers, as described in Sections 7.7 and 7.8.

Material state

INTENT

Tools present materials and allow us to probe and alter materials in a tool-specific manner. They are the key elements of an application system and provide the central interface between the user and the system. Therefore, the tool design has a high impact on the usability of the application.

PROBLEM

Tools introduce special requirements to our design, which means that we have to solve two design problems.

First, we have to define the domain contents or functionality of a tool. Second, we have to give the tool a shape appropriate for representing it in software.

Obviously, we cannot solve these two problems independently of one another.

Unfortunately, we don’t have clear references along the lines of the Bauhaus slogan,

“form follows function.” So what shape or form results from the domain functionality of a tool for a bank account manager or a device manager?

RELATETO

This pattern is related to the conceptual pattern interrelation between tools and materials and the material design metaphor (see Figure 7.4).

SOLUTION

Considering that we are dealing with software as the fundamental “fabric” that our tools will be made of, there are only a few “material-specific” restrictions to be taken into account. This means that, in designing software tools, we basically have to rely on a few good examples of interactive systems and our imagination.

The domain functionality of a tool grows from our experience with recurring activ-ities. For each tool, we have to identify all those recurring activities that should Functionality

of a tool

Material Design

Domain Service Provider