What is the "General Hierarchy Pattern" in software engineering?

Question

I am trying to understand the "General Hierarchy Pattern" but despite my efforts it remains unclear:

• Why is it used and how does it work ?
• How to model it in an UML class diagram?
• What are the benefits that we will achieve by using this pattern?

Answer 1

Where does this pattern come from?

This question raised my attention, since the name of the pattern doesn't ring a bell but the elements provided in the comments strongly suggested some variant of the well-known composite pattern. Some quick research suggests that this pattern is not widely known under that name. Only a couple of books seem to describe it:

• Software Engineering - Principles and practices, by W.S.Jawadekar (description in section 16.2.2) published in 2004
• Object-Oriented Software Engineering: Practical Software Development using UML and Java, by T.Lethbridge & R.Laganiere (description in section 6.3) published in 2001 (second edition in 2004).
• Real-Time Embedded Systems, by Xiaocong Fan (example in section 6.3.4 where it is assimilated to the composite pattern) published in 2015

I could not find any academic article refering to this pattern, at least under that name.

What is the general hierarchy pattern?

The better-known composite pattern describes a general hierarchical structure, in which a component can be made of a hierarchical aggregation of nodes specializing the component, some of them being leaf-nodes. This is a very general design pattern that covers many forms of hierarchical structures.

However, the composite is itself a specialization of the more general "general hierarchy pattern". According to T.Lethbridge & R.Laganiere:

• an abstract Node defines the features and exposes the interface that is common to each node in the hierarchy. Each node can have a "superior";
• there are at least two specializations of the general node, SuperiorNode and NonSuperiorNode depending on whether they must or not have a subordinate (i.e. be the superior of another node).
• the relation between nodes may be any kind of association (i.e. not only aggregation as in the composite), with a multiplicity of optional-to-many (as in composite) or many-to-many

In UML, this would look like:

Personally, I am a little bit perplex with the many-to-many superior. Taking the example of managers and employees, this would look like a matrix, and a matrix is not really a hierarchy anymore. The authors mention that it's a lattice, but without argumenting about the relevance for hierarchies.

Remaining questions about this pattern

It is used for representing any kind of hierarchic structure. For example:

• The manager/employee hierarchy, where a manager can have responsibility over a set of employees, some of these employees being themselves managers with responsibilities on a group of employees.

• The department/employee hierarchy could be modelled using a composite, because a department is made of sub-departments, which are in the end composed of people.

The main benefit of this pattern is that the abstract Node exposes an interface that can be used for all nodes. This facilitates the design of algorithms that can navigate seamlessly through a hierarchy, wihtout having to care for specific details on each different hierarchical level.