FIGURE 6.1 Simplified

model for object-oriented software development.

Application domain

is basis for is basis for

is basis for

affects affects affects

Model of application

domain

Model of application

system

Application system Handling

& Presentation

Technology used

6 . 3 T H E A P P L I C AT I O N D O M A I N

One of the prerequisites for the development of a software system is that we have a definition and a clear understanding of the contents of the application domain con-cerned. This is the part of an organization for which we are to develop application software. This means that the application domain is our starting point and the context for our software development.

Many development methodologies take this understanding of the application domain for granted. They assume that the developers somehow know what domain they have to deal with. In our experience, however, this is a crucial issue within a software project, so we make it explicit in our application-oriented approach.

6.3.1 Definition: Application Domain

Application domains can either be very extensive or very limited. In this book, we see application domains mainly in the context of commercial or governmental organiza-tions, but they could easily be in social or private organizations. Application domains include banks, insurance companies, or hospitals. In this book, equipment manage-ment for a small software company is our main example. Internet applications have become increasingly important, especially for the home and entertainment domains.

An application domain is the segment of reality for which a software system is developed. It is the background or starting point for the actual-state analysis and the creation of a domain model.

An application domain can be an organization, a department within an organiza-tion, or a single workplace.

The concept of an application domain is at least as wide, so that the domain con-cepts and relations relevant for the construction of models can be well under-stood during the analysis of the actual state of the domain. On the other hand, its extent should always be limited, that is, never be too complex.

An application domain normally includes a domain-specific language. This means that people in this domain use specific terms and concepts and think about their domain in a specific way.

6.3.2 Discussion: Analyzing the Application Domain

The application domain is very important, because it is critical for our application-oriented way of developing software. The developers analyze and describe the actual tasks and situations (see Section 6.41) that characterize the application domain in the domain-specific language. This corresponds to an actual-state analysis, where the typical processes and the objects used in these processes are represented in their domain-specific use contexts, for example, as scenarios or glossary entries (see Section 5.3.11). It is similar to the business model in UP. At the same time, the application domain is the basis for the construction of a domain model. Together with the analysis and description of the actual state within the application domain, we are gradually building the domain model.

This model represents the segment of the actual application domain to be supported by the software system under development. Obviously, our domain model is similar to the domain model in UP. Later in this chapter, we will explore the question whether or not the UP domain model can meet all our requirements, that is, easy to understand and easy to construct, as one model.

This interest of developers in an application domain is not limited to the segments that will be mapped in the domain model; they will also deal with segments required to understand the current work situation within the actual-state analysis. It is at once a risk and an art to find the right limits for the actual-state analysis, and not to let it get out of hand both in terms of time and content. Experiences from traditional data-modeling projects have shown that it is simply not possible to achieve a complete analysis of the entire application domain. The first notion of the future application sys-tem will help developers find the right point to stop analyzing. This means that the developers have to gain quick insight about the points of the application domain where software support could be useful and feasible.

Our recurring example has made clear so far that the software support for equip-ment manageequip-ment in our small software company has been rather poor. Once we dis-cussed the possibilities of supporting the management’s work with the employees, we soon found out that they wanted us to design a more extensive planning system for all tasks involved in the company’s business. However, the developers found that the addi-tional domain issues and problems would far exceed the project is resources. For this reason, we knowingly reduced the analysis of the relevant management and planning tasks to the actual equipment management. Issues like scheduling or job distribution were no longer taken into account.

6 . 4 T H E D O M A I N M O D E L

In the T&M approach, object-oriented software development means the reconstruction of domain terms. As trivial as it may sound, this requires that the developers understand the underlying concepts.

Developers create an explicit domain model with all the domain objects, terms, and relationships existing in that application domain. This model is oriented to the existing situation in the application domain and the domain business processes.

Besides the Unified Process not very many development strategies acknowledge an explicit model of the application domain. But within an application-oriented approach, modeling the application domain and designing the future system are intertwined. Thus a well-designed domain model is a strong foundation for the software system to be built.

6.4.1 Modeling Your Application Domain

The domain model describes the elements and relationships to be supported by our application software from the domain view. In our T&M approach, we begin with the tasks and then identify relevant objects and their usage forms or interactions.

An interaction is a characteristic action that can be done on or with an object.

Building a domain model

The EMS example

Reconstructing domain terms

Once we have identified the objects and interactions and abstracted the terms, we map them to the domain-specific language and model their relationships, using object-oriented concepts like generalization, composition, and dependence. This means that we model the application domain.

The domain model includes all aspects of the application domain to be potentially supported by an application system. This model is oriented to the tasks and the relevant objects, including their interactions. Generalization and composition are used to represent the related terms in a domain concept model. When cre-ating this model, we orient ourselves to a guiding metaphor and its design metaphors.

The domain model consists of the concept model and selected application-oriented documents (e.g., scenarios, glossary entries, and cooperation pictures).

When modeling the application domain, we usually write scenarios and glossary entries (see Sections 13.1 and 13.4). This corresponds to what is called “business mod-eling” in UP. As we continue dealing with the application domain, we identify depen-dencies and similarities behind the key terms and notions in these documents and eventually collect them in a separate concept model (see Section 13.3). This could be compared to the business modeling in UP.

When identifying the relevant objects, terms, and relationships, the guiding metaphor and its design metaphors (see Chapter 3) are extremely helpful, as they guide us in dividing all the things relating to a workplace into categories, such as, tools, materials, automatons, or containers, and to look for appropriate properties that char-acterize them.

The example in Figure 6.2 shows a segment from a bank-specific concept model, or, the securities hierarchy for a loan system. In this scenario, a bank requests some form of security before it grants a credit to provide collateral in case the borrower defaults in payment. The model’s broad differentiation in width and depth means that several author-critic cycles have been completed.

As we work towards a concept model, another useful tool is CRC cards. We can use CRC cards to identify services offered by a domain object. We also include those

Mapping domain objects to model concepts

FIGURE 6.2