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.
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.
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.
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.
|C||Consistency & completeness||P||Provided interface|
|G||General definitions||R||Required interface|
|I||Include relationship||U||Use & inheritance relationships|
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:
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.
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.
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.