Each composite object can contain elements, therefore we add an associ-
ation from Composite to Element . But a composite can be contained within
other composites, i.e. it behaves like an element, therefore class Composite
inherits from class Element . The new classes are shown in Figure 8.10.
There are several advantages with this solution. The atomic elements and
the composite elements are clearly distinguished in the class diagram. The
class structure is less complex and easier to understand than the previous
one. Finally, the methods to compose elements and serialize composite ele-
ments are written once in Composite .
Other elements can be added to the class structure easily, i.e. the elements
Ul and Li representing a bulleted list and the items of a list respectively.
The main difference between this design solution and the previous design
class diagram is that, based on the semantics of inheritance and aggregation,
any composite object can (in principle) contain any other composite or
component object. Consequently, containment constraints need to be
graphically documented by means of notes attached to the classes in the
Here we present the implementation of the classes that have been defined
for this prototype. All the classes that implement the HTML object model are
in the package HtmlDOM:
and one Body
Page or Head
Figure 8.10 Refined design class diagram