nocollapse)

HOOD

• You can also go to the documentation area.

The Hierarchical Object Oriented Design (HOOD) method was created in the late eighties by the European Space Agency in order to provide a Model Driven solution on top of the Ada programming language for its large scale projects such as Ariane, Hermes and Colombus. As opposed to the AADL or UML, HOOD is not only a modeling language and also defines a complete development process from requirements analysis to code generation of distributed real-time Software.

The hierarchical approach

With HOOD, a project is composed of a set of main modeling units called Designs. A design can lead either to a completely autonomous Software application (an executable file) or a library of linkable Software entities (functions, data types, classes, ...). Moreover, dedicated categories of designs have been defined to support parametric reusable components (Generics) and Software partitioning of distributed Systems (Virtual Nodes). Each HOOD design is the root of a hierarchy of components that is usually built following a top-down approach that drives the architectural design phase of the Software development process.

Low coupling

Each HOOD component can be represented by a black box view that exposes a Provided Interface and a Required Interface, and a white box that shows subcomponents in case of a non-terminal object of the design hierarchy or the implementation of the actual Software entities (functions, data types, variables, constants, exceptions) in case of a terminal object. The criteria for this top-down decomposition of the System is given by the very intuitive "low coupling" principle: all the entities that interact the most together must be located within the same branch of the hierarchy. This leads to an architecture where residual connections between the various Software units are minimized, which is a key for building easy to integrate and to maintain Software applications.

Design rules

HOOD enforces client-server communications between interacting components. As a consequence, all these interactions are implemented by function calls. In particular, standard HOOD rules recommend to forbid direct access to shared variables and to implement all the data-flows by subprogram calls. Moreover, in order to properly manage team development, modular deployment and maintenance of the applications, HOOD imposes rigorous visibility rules than can be easily checked at design level.

Real time model

The HOOD modeling constructs include active components to support concurrent control-flows within a same Software application. Communication protocols between active components are defined on the top of the basic client-server model and include highly synchronous, loosely synchronous and asynchronous paradigms. A specific version of the HOOD methodology, called HRT-HOOD introduces more precise real-time components such as cyclic periodic and protected objects as well as real-time attributes to handle timing properties for scheduling analysis purpose.

HOOD and AADL

Due to the numerous similarities between the AADL Software components and the architectural design constructs offered by HOOD, Ellidiss technologies has been able to integrate most of the AADL into its Stood tool which was initially developed to support HOOD methodology. Nevertheless, the scope of these two model based engineering solutions remains complementary, as the AADL also provides support for earlier phases in the development life-cycle as well as for modeling the Hardware part of the application, whereas HOOD, thanks to its support for detailed design activities, covers well coding and documentation phases. By offering both AADL and HOOD inside its Stood tool, Ellidiss provides a unique solution to reduce the gap between System and Software engineering activities.


Back to the top of the page.