T HE S YSTEM B ASE

If the applied technique for our system is available in the form of real components, then we can use it directly. In the implementation model, these components are then used through interface libraries or frameworks. All these components combined are called the system base.

The system base includes the set of all interfaces to the (external) technical com-ponents used in the implementation model.

The EMS example

To be able to use a software system in different hardware and software environments, the system base is normally encapsulated in a portability layer. But an explicit system base layer isn’t necessary when portability is supported by a large number of commercial APIs (Application Programming Interface), as in Java.

THETECHNOLOGY

The system base and the technical concepts used are normally connected, because the developer has to have models of the applied technique to be able to build a design or implementation model.

Technology denotes the developer’s conceptual knowledge of the applied tech-nique. When creating the application system model, this knowledge has to reflect in an explicit or implicit model of the applied technique.

If we consider this statement in our EMS example, we could implement the registry for devices and room plans by the use of a relational database. However, it is not sufficient simply to install such a database. The software developer has to have an implicit or explicit model of this technique. This is the only way for him or her to identify the need to add mapper classes to the domain classes of his or her model, so that the data-base can be linked. The same applies to the use of program libraries or frameworks; you can hardly use them meaningfully unless you have an idea about software architectures and design patterns. This knowledge of the underlying concepts behind the technical components is called technology.

6.7.5 Handling and Presentation

The third context, handling and presentation, is relevant in the development of interac-tive application software. This context denotes how a software system is presented to the users and how users can manipulate it.

Handling and presentation is the way in which we implement the usage model of an application system.

● The usage model of an application system shows in its handling and presentation.

● Handling defines the ways how you interact with a software system, while its presentation defines how it looks and feels from the users’ perspective.

For a single system functionality (as part of the business logic), there may be more than one type of handling and presentation within an applications system, depending on the workplace type and guiding metaphor. The same also applies to a certain extent to applied technique, which means that given a specific technique you have several options to realize the handling and presentation of a system.

There are separate concepts and models for the handling and presentation of an appli-cation system. Concepts like electronic desktop, direct manipulation of graphical icons, and mouse interaction are obvious components of a system’s handling and presentation.

For systems based on the T&M approach, handling and presentation is a particu-larly important context, because these elements clearly show the fundamental concepts of T&M, like structural similarity and application orientation.

The EMS example

6.7.6 Discussion: Handling and Presentation

To combine the different concepts for handling and presentation into a uniform picture, we select a guiding metaphor with matching design metaphors (see Section 3.3).

Though a guiding metaphor with its design metaphors does not define a specific usage model for an application system, it gives the developer some orientation for designing the software. This guideline is strengthened by a selection of the matching workplace type. Nevertheless, considerable freedom of decision remains for the design of an appli-cation system’s handling and presentation.

The fact that handling and presentation form an independent context, similar to the application domain and applied technique, is often overlooked. The reason is the matter-of-factness in which we use interactive software today, as well as the uniformity of current workplace systems, at least as far as this aspect is concerned.

However, we should bear in mind that the selection of so-called “middleware” and frontend technologies have a strong influence on how a software system can be manipu-lated and presented. For example, an Internet-based PC application implemented in HTML and Java Server pages offers very limited interactive feedback to user-input.

Though a WAP (wireless application protocol) solution for mobile phones uses an interaction model similar to the PC-based browser solution, the much smaller display size limits your freedom of design.

When designing application systems like the one in our EMS example, interaction with the system is often a major problem. How should we represent the room plan and the available devices? What manipulation can we support for the tools? How would working with the room plan influence the staff list? The answers to these questions may be totally different, even for the same application domain and the same applied tech-nique, but our practical experiences have shown that they will always contribute to the usage quality of an application system.

6 . 8 C O N T E X T S I N F L U E N C I N G T H E S O F T W A R E A R C H I T E C T U R E

We know from previous sections that the individual contexts involved in a software development project are relatively independent so that they can change indepen-dently. When preparing an architectural model, we should take these potential changes into account. The idea is to isolate the influence of the different dimensions from the software architecture. According to the principle of structural similarity, every context dimension should be reflected by a set of system components. Changes to one context have to be encapsulated in the components of your application system in such a way that they will not affect other components. This section discusses how contexts may influence your software architecture.

6.8.1 Discussion: How Contexts Influence Your Software Architecture

Experience has shown that contexts can change more or less independently. For example, window systems with new functions are introduced to the market; some busi-ness requirements in the application domain have changed; users want to see modern Handling and

presentation is an independent design context

The EMS example

Contexts change independently

interaction forms (e.g., hyperlink navigation in the World Wide Web) implemented in their application system.

A closer look reveals that, although the three software development contexts discussed here are autonomous, they are not entirely independent of one another. Accordingly, as soon as there is a change to one context, we have to find out how this change may affect the application system and the other two contexts. To facilitate this job in software pro-jects, we clarify and discuss the costs, problems, and influences of such a change.

Let’s see how these issues might look in our EMS example. Assume that some people suggest in the planning phase that we should use Java instead of Cfor our equipment management project. At first, this change appears to affect applied technique and thus only the implementation model. A closer look reveals that we cannot link all existing compo-nents in Java, because some proprietary interfaces may not be available. Considering that Java and Cuse different object metamodels (e.g., no multiple inheritance), we have to change the software architecture and the patterns. Switching to current GUI libraries results in additional new handling and presentation opportunities that we should utilize.

In this example, the impact on the domain model is negligible. After all, we want to develop an interactive application system, and Java is suitable for our application domain. If we transfer these considerations to a simplified dimensional model of the three contexts, we get the scenario shown in Figure 6.6.

The contexts as

FIGURE 6.6 Software development contexts and models.

Let’s return to our EMS example. Once the equipment management system has been used successfully at the device manager’s workplace, the device manager suggests making the system available as well for secretarial workplaces. He argues that this would allow the secretary to enter personnel changes and moving requests, things han-dled by the secretary, directly into the room plan. Naturally, the change resulting in the application domain has a direct impact on our domain model. If we are to ment this idea, we need at least a simple client-server model and an appropriate imple-mentation. In addition, it turns out that we should implement at least a minimal cooperation model on the handling level to allow the device manager and the secre-tary to concurrently use the staff list or the room plan. Though this is primarily a domain-specific change, it affects the other contexts, as shown in Figure 6.7. We have to think about extent that these changes should have over the other dimensions, and how this would influence our application system.

6 . 9 R E F E R E N C E S

D. Bäumer, G. Gryczan, R. Knoll, C. Lilienthal, D. Riehle, H. Züllighoven: “Framework Development for Large Systems.” Communications of the ACM, October 1997, Vol. 40, No. 10, pp. 52–59.

An article on modeling in framework design.

E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns. Reading, Mass.: Addison Wesley, 1995.

Some patterns described in the book are referenced in this chapter.

Handling & Presentation

installation of a 2nd device management system

Application domain use of

Java

Technology used

FIGURE 6.7