3. Overview of HOOD

HOOD is an architectural design method, helping a designer to partition the software into modules with well defined interfaces that can either be directly implemented or further partitioned into modules of lower complexity. It supports functional approaches as well as object based and object oriented design. It integrates both modular programming, centered on client-server and composition relationships, and inheritance programming.

HOOD was developed as a design method, with special consideration for other development activities that occur at the same time: smooth integration with requirements analysis, concurrent development of independent parts, automated code generation and testing, client-server and post-partitioning support. The integration of these aspects results from the return of experience gained from using previous issues of the method on industrial projects, thus making HOOD the architectural design method of choice.

3.1 Objectives of industrial software design

Complexity

There are several issues that make software development such a challenging endeavour. But encompassing all the others is the issue of complexity. It has long been observed that the human mind is limited in its ability to handle complexity [Miller56]; at the same time, software becomes increasingly complex. Therefore, as Booch points out [Booch91], "the fundamental task of the development team is to engineer the illusion of simplicity". But this does not happen through wishful thinking: design methods are intended to guide the developer into achieving this goal.

One of the issues that makes software complex is that there are several aspects to it: what to do, when to do it, and how to do it. A design method can help if it separates concerns, allowing the various aspects to be dealt with without introducing any coupling between them.

Reuse

Software is rarely entirely new; reuse of existing modules in new projects is often a concern. It is not something that happens by chance, and a structure is necessary in order to identify the pieces that can be reused, at design level as well as at code level.

Hardware vs. software

Most modern systems involve a network of computers, or at least several collaborating processes. The hardware architecture is often driven by external considerations, such as cost, power consumption, network bandwidth, etc., that do not necessarily map the software constraints; on the other hand, software is developed concurrently with hardware, and cannot rely on a definitive hardware architecture. Moreover, software changes and evolution should not have an adverse effect on the effectiveness of hardware usage. For these reasons, a design method should allow concurrent development of hardware and software, and provide for a late mapping of software upon hardware as well as for an easy remapping if necessary.

Traceability

It is a fact of life that requirements keep changing, long after design has started. Evaluating the impact of a change is difficult, but it can be eased if there are good traceability documents, that tell precisely which parts of the design are impacted.

Partitioning

Finally, large projects are seldom built as one piece. There is often a prime contractor who delegates part of the development to several subcontractors; the global design process is split into several concurrent activities. Even if the project is completed within a single company, it often requires several development teams. This implies that software must be partitioned between the various proponents, and that synchronization and consistency checks have to be done between loosely related participants. This aspect has a real impact on software design: what good is a software architecture if it is not feasible in time by the people in charge? It also implies that a design method must provide a common language for expressing strictly defined interfaces, allowing subcontractors to understand what they have to do, and allowing the prime contractor to check the resulting design against the specifications.

3.2 The HOOD approach to design

HOOD is a design approach, that uses standardized (textual and graphical) formalisms to express the results of the design. A number of rules, elaborated from industrial experience, apply to the design, and these rules can be checked by automated tools. The final goal is to achieve the best possible quality design.

3.2.1 The hierarchical approach

Since HOOD is a design approach, it provides a framework to guide the developer in the design activity, by describing and refining a software model from abstract structures and concepts towards machine code. Each step produces pieces of text reflecting the associated design activity, that can be reviewed and checked against quality criteria. Moreover, HOOD is a hierarchical approach: it defines high level structures that are refined into more detailed ones; the designer never has to cope with all the project's details at the same time. This dramatically reduces the complexity the designer has to deal with at any moment. The hierarchy can be organized according to management constraints, such as subcontracting or other organizational aspects.

An original aspect of the approach is the separation of concerns: each module includes separate descriptions for interfaces, functional aspects, data modeling, and behavioural aspects. The descriptions are kept independent, making it easy to apply dedicated development skills, and rigorous methods. For example, Rate Monotonic Analysis [Klein93], State-Transition or Petri nets [Reisig85] analysis, automated test scenario generation, can be applied to the behavioural part without relying on an implementation of the functions, while functional parts use abstract state machines, preconditions and post-assertions for functional proofs.

Separate hierarchies are defined for reusable software components. This allows for introducing a reuse policy as a natural step in design. Moreover, the notion of system configuration (see section 12.3) allows precise tracking of which components (design pieces as well as software components) are being used in each project.

Traceability with requirements as they are refined, followed by refined solutions, is still a problem in managing large projects. HOOD refinement properties support a development approach that encompasses the different design phases and helps ensuring consistency and traceability of a design solution, from requirements to implementation, even in the presence of unstable or evolving requirements.

Finally, the method includes an abstract model of distribution (the virtual nodes, see section 6.3) which is orthogonal to the structural design. A separate step is used to map the logical architecture into the physical one; this ensures independence and ease of relocation between software and hardware.

3.2.2 Balancing graphical and textual formalisms

HOOD includes the definition of a graphical description (i.e., boxes and arrows). It provides an abstraction of a solution with a clear, high level and easy-to-understand formalism. It offers a reduced, but consistent view of objects, and allows hierarchical refinement and easy understanding of the solution.

The notation is intended to support the approach, not to replace it. It is a convenient way to reason about software and to make a mental picture of its architecture, but not more. Therefore, the graphical description is complemented by a textual description which includes all details. It allows formal expression and refinement of the object's characteristics and properties by an Object Description Skeleton (ODS). This concept helps structuring the descriptions into separate fields which support appropriate control and program description notations. Finally these descriptions are translated into a target programming language (Ada, C, C++, or FORTRAN, for example).

The textual notations leave provisions for both informal and formal texts, allowing the definition of a documentation skeleton which can serve as a framework for a step by step integration of advanced notations (like Petri nets for example). Tools can be used to capture and formally verify the characteristics of objects.

The graphical notation recalls the context of the design piece, but hides most implementation details, thus decreasing the design complexity, while the textual notation keeps all the details, including full traceability and control of dependencies between modules, with full consistency checking. These notations allow to use powerful structuring concepts for describing and organizing a system as a set of interconnected hierarchies of objects.

3.2.3 Design quality control: HOOD rules

Proper usage of HOOD requires obeying by a number of rules. Rules may appear as a nuisance to the stand-alone designer if they are perceived as arbitrary restrictions; on the other hand, they can be of great help when they are perceived as providing guidance, common guidelines, and thus forming the basis of quality assurance. The rules are summarized in section 16 of the HOOD Reference Manual. Each rule is assigned a number for easier reference, that includes a letter that classifies the rule, and an ordinal number. The keys for the rule letters are as follows:
C Consistency & completeness P Provided interface
G General definitions R Required interface
I Include relationship U Use & inheritance relationships
O Operations V Visibility

HOOD rules are of three kinds: definitions, methodological rules and usage rules. Definitions are simply statements of the main method elements. Methodological rules result from the very structure of the method's entities . They must be enforced, or else the design would be inconsistent. Usage rules come from industrial experience. They are intended to help the designer and provide a basis for quality assurance, but there may be cases where an out-of-norm situation may lead to not obeying by the rule. Such exceptions must be documented and justified in the design documents.

In the book, we introduce rules as we encounter the corresponding situation. They are presented in a special box, to stress that they are formal rules, as follows:

Reference Number
Kind
Text of the rule
The reference number is as given in the reference manual, the kind is one of "Definition", "Methodological", or "Usage", and the text is the text of the rule as given in the reference manual. Note that "Usage" rules are not formal rules, and thus have no reference number.

3.2.4 Supporting the method: HOOD tools

HOOD was designed right from the start with consideration for tools support. What this means is that tools were not added later, but that it was rather considered that tools were in any case necessary for any serious software development. The notations, the rules, and even the format of the design documents have been designed for being produced by tools and for being reviewable by tools.

What do the tools bring to the designer? First, they help with the design activity itself, by providing graphical and textual editors. They can generate documents according to various documenting standards (like DOD-2167A, DOD-198A or ESA PSS-05 [BSSC91]). They check and insure consistency between the representations. They can enforce HOOD rules, and provide various analysis of the design. For example, a typical output of such a tool is represented on figure 1-1.

Figure 1-1: A HOOD checking tool (Concerto, SEMA-Group)

Moreover, it is possible to extract parts of the design for processing by other tools, like proof making tools for example.

Several tools are currently available from various vendors, and this is a competitive market. HOOD defines a standard representation of designs (the Standard Interchange Format, or SIF, see section 19.3) that allows a design produced by a tool to be read by a different tool. This way, several subcontractors on a project need not use the same tool in order to exchange design documents.

3.3 From analysis to design: scope of HOOD

HOOD supports identification of a software architecture after requirements analysis activities and leads naturally into detailed design where operations of objects are further designed and implemented. This detailed design description may be further refined into target language descriptions up to a point where the target code can be generated. Figure 1-2 indicates HOOD applicability within a simplified life cycle model.

Figure 1-2: HOOD in the development activities

Although HOOD is not a requirements analysis method, it handles "design requirements analysis" activities during the transition from requirements analysis to design. From this point on, it covers all phases of architectural design and detailed design down to coding, which can be greatly automated, and testing.

HOOD concepts are intended for easy integration of design with other development activities. More precisely, HOOD object properties have been defined in order to ease interface mastering, testing and integration in the context of parallel, multi-people team developments. This implies that HOOD is rather aiming at better filling the needs of the prime contractor and integrator than those of the low level programmer.

3.4 HOOD compared to other methods

As noted above, the challenge for a design method is to guide the developer in order to design complex software while giving it the look of simplicity. Many design methods fell into the pitfall of trying to accurately represent all of the complexity of the problem to be solved, while HOOD focuses on hiding the complexity by organizing the development in such a way that the designer, at any one moment, only has to cope with a well defined and bounded part of it that is within the reach of human understanding. This is the key concept that introduced the notion of hierarchical design.

Analysis methods, such as OMT [Rumbaugh91], are very efficient methods for representing the properties of system. As such, they are very fit as a requirements analysis method, and can actually be used as the input to a HOOD design. On the other hand, there is no clear module interface definition, so using it as a design method will badly lack context restriction, interface definition, testing and integration support.

The so-called object oriented methods (actually, inheritance based methods) provide excellent flexibility when in the exploratory stages of a project; but it is often at the cost of difficulties in traceability, testability and maintenance. By limiting inheritance to data structures in a very controlled way, HOOD achieves many of the benefits of these methods, without the drawbacks.

Finally, a special mention should be made to explain the relationships between HOOD and UML, the Unified Modelling Language [UML]. UML is a very general language, that can be used to describe various systems; it has been designed by merging concept and notations from OMT, Booch and OOSE methods. UML includes a graphical representation of the formal language. UML (purposely) does not include any design process; it is rather expected that various design processes be defined using this language. The general notation can be specialized, by identifying certain uses of the constructs as bearing some special semantics; such specializations are called stereotypes.

HOOD concepts can be described using UML, adorned with a number of ad-hoc stereotypes, and the HOOD method itself can be described using UML as a meta-model, the same way as UML is itself described using its own meta-model. In a sense, HOOD can be seen as one of the many possible design processes obtained by specializing UML. HOOD is not UML, but HOOD is compatible with UML.

HOOD notations differ in a number of places from UML notations. On one hand, when the same need arises in both approaches, it would make no sense to invent a different shape of arrow, and HOOD uses the same (or similar) notations as UML; on the other hand, when a stereotype is a cornerstone of the method, it does make sense to identify it by a special symbol to make it more easily recognizable than a simple annotation on a standard diagram. Deciding which level of concepts is worth a special symbol is a matter of judgement, but the apparent differences between the notations should not be taken to be more than what they are: various ways of representing the same underlying model, and it is absolutely possible to design a HOOD tool that would, at a user mouse click, present the design using either notation.

3.5 Summary

HOOD is a hierarchical design approach that incorporates the notions of object oriented design into an industrial process. It includes a notation and a design process. The formalism is supported by a set of rules which are enforced by tools.