Structure of Holmes

Holmes incorporates five main sources of information: domain definition, domain characterization, domain scoping, domain modeling, and domain framework development. By "domain" we refer to the problem domain, which the software system should address. By "source of information" we refer to key information required to develop the final system. Notice that these sources of information constitute a core of data that can be mapped to any of the results of tasks of any software endeavor, from the initial conception to the actual implementation.

Applying Holmes in an existing context requires linking each phase of development to these five activities. In the case of XP, we would tie the user stories to domain definition, the planning game to domain characterization, and so on.

During domain definition, the boundaries of the domain are defined information from the users and domain experts is collected and organized in an appropriate form: user stories, use cases, or more formal requirements specification. Also, a preliminary analysis that determines the feasibility of the project is performed.

All the domain terms that are entered in this phase and are used in the other tools of Holmes are recognized automatically and turned into hyperlinks (see Figure 41.1). Thus a software practitioner can easily refer to the description of a given domain term. Similarly, the products entered into classified information are automatically added in the phase of domain characterization (see Figure 41.2). Any modification to a term is automatically propagated to all occurrences of the term in the system.

Figure 41.1. Domain definition

Figure 41.2. Adding the description of a new product

Thus, any information that spans multiple phases is added only once. Given that model keeping data consistent among all phases of the tool support for CRC cards can be easily added, and the classes associated with a given CRC card can be linked to it.

Domain characterization analyzes existing products that address the same or similar problems, and evaluates the possibility of adding some of their features in the future. That information is used to determine how the product may evolve and the minimum set of features that should be implemented to provide the highest value to the user.

Domain scoping deals primarily with prioritizing what should be developed next. Different variations of the product are considered by including a different subset of all features required by the customer or envisioned as possible future extensions. This is the crucial information for performing an informed planning game.

Domain modeling captures the requirements from the analysis of the product in the previous stages. It presents these requirements in the form of object-oriented modes, such as the CRC cards.

Domain framework development focuses on collecting the critical information for and from coding the final product. The framework consists of components that can be reused later in different parts of the software system. The reuse does not occur thanks to up-front decisions. Instead, having developed everything with a clean and coherent approach enables considering components for subsequent reuse.

A critiquing system permeates all the phases, enabling the system to provide customized semantics support for the different phases. The supporting system is customized with Prolog-based rules. It is within these rules that all the wisdom of XP can be put into practice.

The architecture of Holmes is completely open (see the next section for details), enabling complete integration of external tools. As mentioned, this is a key requirement for a lightweight introduction of Holmes.

Support for refactoring and unit testing can be provided by integrating some of the existing tools. Refactoring and unit testing can also take advantage of the critiquing system to reveal specific "patterns." Situations can be identified where refactoring and unit testing can be applied, and suggestions on how to perform them can be presented to developers.

Each part of Holmes can be logged for time elapsed and effort spent, and additional metrics can be extracted for subsequent business intelligence activities.