Structural Composition

Intent

The Structural Composition pattern is used to describe how a system is composed of constituent parts, which may be in turn further composed of other parts, etc. Note that this pattern applies only to homeomeric composition, in which the whole and its parts share some common kind. The breakdown of a mechanical assembly into mechanical parts is homeomeric, whereas a grouping of requirements by some category (e.g., environmental) is not, in the sense that the collection is not itself a requirement.

Motivation

Engineering of complex systems nearly always involves a process of decomposition and delegation. The system itself is decomposed recursively into lower-level constituents with corresponding requirements, and design responsibility for those constituents is delegated to lower-level authorities (as conveyed by the Work Breakdown Structure). The Structural Composition pattern gives us the grammar to express the system decomposition. The canonical Structural Composition in Systems Engineering is the Product Breakdown Structure.

Applicability

Many system properties of interest (e.g., mass, cost) can be defined recursively with reference to a structural composition. For example, the mass of a whole is the sum of the masses of its parts.

Note that structural compositions may have different interpretations in different contexts. For example a system may be decomposed into its physical parts, their parts, etc., as part of an assembly bill of materials. Alternatively, it may be decomposed into abstract performers of function where the parts do not necessarily represent physically distinct elements, but groupings of related function, e.g., attitude control, telecommunications, propulsion, etc. These two viewpoints are each a valid application of Structural Composition, but they are distinct uses of the pattern with distinct interpretations.

A key distinction of Structural Composition is that each node in the composition may be a part of at most one containing node. The underlying mathematical representation is a directed rooted tree, or out-tree.

Structure

[We'll have to decide on some graphical conventions.]

Participants

The only class that participates in Structural Composition is mission:Component (and, of course, its subclasses). No data properties are required, but any identifying properties (e.g., name) or properties pertinent to a particular compositional viewpoint (e.g., mass) may participate.

Collaboration

The only object property that participates in Structural Composition is base:contains (and, of course, its subproperties).

Consequences

One important benefit of using the Structural Composition pattern (where applicable) is that well-formedness of the pattern is enforced by semantic constraints of the fundamental property: base:contains is inverse functional, which implies that a mission:Component can be contained in at most one other mission:Component. Any violation of this constraint will be detected by an OWL reasoner.

A further benefit is that any property that can be defined recursively can be computed concisely and efficiently by exploiting the fact that a tree is a recursive structure. For example, "the mass of a parent is the sum of the masses of its children" can be written a just a few lines of any modern programming language. Contrast with a spreadsheet implementation in which the summing algorithm must be repeated for every component, perhaps thousands of times.

Implementation

The following examples illustrate implmenentation of the Pattern in OWL 2 Functional Syntax.

TBox Interpretation

# Create subclasses of mission:Component for parent and children

SubClassOf(my:ParentComponent mission:Component)
SubClassOf(my:ChildComponent1 mission:Component)
SubClassOf(my:ChildComponent2 mission:Component)

# Every member of parent contains at least one of each child

SubClassOf(my:ParentComponent ObjectSomeValuesFrom(base:contains my:ChildComponent1))
SubClassOf(my:ParentComponent ObjectSomeValuesFrom(base:contains my:ChildComponent2))

ABox Interpretation

# Create named individuals of mission:Component for parent and children

ClassAssertion(mission:Component my:parentComponent)
ClassAssertion(mission:Component my:childComponent1)
ClassAssertion(mission:Component my:childComponent2)

# Parent contains children

ObjectPropertyAssertion(base:contains my:parentComponent my:childComponent1)
ObjectPropertyAssertion(base:contains my:parentComponent my:childComponent2)

Known Uses

[Examples of real usages of the pattern.]

Related Patterns

[Other patterns that have some relationship with the pattern; discussion of the differences between the pattern and similar patterns.]