Derived, Middle, and Inner elements – Basic guidelines

Relatics is the leading software for supporting Systems Engineering in construction projects. Relatics is very flexible and through the so-called Systems Engineering Model – “SE model” for short -, each project team can tailor the software to their own specific way of working. In the SE model the project team defines the elements, properties and relations being recorded in Relatics. An adequate SE model allows Relatics users to recognize their ‘project reality’ instantly. This article is a sequel to the article Element, Property, Relation – Basic guidelines where the essential objects were introduced. In the next, we provide guidelines for ‘variations’ on these essential objects.

Derived element

Suppose the client and contractor keep work packages as the unit of work to communicate about things like delivery and finance. To keep matters manageable internally, however, the project team needs a more fine-grained unit of work. Therefore, they ‘decompose’ work packages into activities. Inversely, a work package can be seen as the aggregation of activities.

The straight-angled slope of the relation reflects that [Work package] and [Activity] are understood in a mutual aggregation/decomposition relationship. This setup has far-reaching implications. For example, when a user duplicates a work package, the resulting copy will consist of copies of each activity that was part of the original work package. And when a user deletes a work package, the result is that each of its activities is deleted together with the work package. Note that this is different from the behavior around a ‘standard’ relation, where the deletion of one element never propagates to related elements and is even completely blocked by any incoming relation.

Modeled as above, [Activity] is called the derived element of [Work package], whereas [Work package] is called the origin. By definition, a derived element has only one and always one origin. In our example, an activity cannot simultaneously be part of two different work packages. Furthermore, an activity can only exist as part of a work package. So, when a user wants to add an activity to a work package, it does not make sense to let them choose from the set of already existing activities. After all, each existing activity is already part of its own work package. Instead, the user both creates a new activity and relates it to a work package in one operation.

One nuance has to be made here. The aforementioned aggregation/decomposition relationship should not be projected too literally on the real physical world. Instead, it is better to consider an element an information compound of more fine-grained data elements. Just as a property has to be part of its element only in an information-technical sense, similarly [Measure] modeled as a derived element of [Risk] is entirely valid (provided that it is desired that copy or delete operations on a risk cascading to the involved measures).

For the cases that have a strong correspondence with real-life aggregation/decomposition, though, the tree view of the Relatics software might be instrumental.

Let’s look at another example. A system breakdown structure (SBS) is typically a hierarchy of system objects consisting of smaller objects. These smaller system objects, in turn, consist of yet smaller system objects. Of course, we can define a separate type element for each level of aggregation/decomposition. However, when the type relations and type properties of elements are the same for each level in the SBS, there is a much more elegant solution.

Note that this keeps the SE model manageable and at that, it is more true to how a system is broken down into smaller and smaller subsystems.

Defining an element as a derived element offers different functionalities in operations like copying, deleting, and creating. Specifically, the ability to both create a derived element and relate it to an origin makes it tempting to overapply derived elements. For example, it sounds user-friendly if to-dos can be created ‘under’ the responsible person.

However, all edit characteristics around a derived element come in one package. That is, when a person is duplicated, this results in a copy of each to-do of the original responsible person. Moreover, a person can be deleted without further ado and all their to-dos will be deleted along! And how about a to-do for which it has yet to be decided who will be responsible? As explained, you cannot create a to-do as a derived element without a person as the origin. All this indicates that [To-do] should not be modeled as a derived element.

You might reason that a user will rarely delete or copy a person and that we always know who is responsible (yeah, sure) and thus, the advantages of a derived element outweigh the disadvantages. But these are delicate trade-offs. They depend on factors constantly evolving along a project’s life cycle. In early project phases, the focus will be more on creating new elements and relations, while in later project phases, the focus will be more on adjusting information. Furthermore, an SE model is constantly evolving, just like the Relatics software itself. Altogether, what seems an intelligent trade-off today may turn out to be as counterproductive tomorrow.

Resist the temptation of exchanging desired functionality against undesired functionality. Don’t let users get used to creating to-dos ‘under’ a person if there is a great chance you have to disappoint them later on because you have to withdraw the create shortcut. Instead, stay true to reality, for this will save you from undesired surprises in the future. Just face it: a person cannot be understood as an aggregation of to-dos.

Inner element

Suppose we want to record an address for each organization. The image below shows three options to define this in an SE model.

The left-hand side shows the most basic SE model, where {Address} is just a free entry property. Addresses can be recorded even if the formatting of addresses is not known in advance or formatting varies between different organizations/countries.

In the center, the image shows an SE model where different parts that comprise an address are split across various properties. This helps users when entering a new address because it works as a checklist. Additionally, it gives more control over how well address info is filled in. For example, finding which organizations are missing a ZIP code is easy. The most essential advantage however, is that this solution enables a user for example, to retrieve all organizations in “Germany”. This can be helpful if the project team wants to do a tour along all German stakeholders. Verify that the last two examples were not easily achieved in the previous basic solution.

While the middle solution offered advantages, a drawback is that it does not communicate that {Street} and {Number} do have more in common than only being properties of the same element [Organization]. Instead of prefixing all Properties with “Address_” or ugly fixes like that, we move to the rightmost solution, where [Address] is explicitly extracted from [Organization] as a separate element. This is the sweet spot between the two previous solutions of merging all address information in a single property vs. splitting address information across different properties. The coherence between the different address parts is now modeled explicitly. Via the settings can be controlled whether an organization can have one address at most or, that the same organization can have several addresses.

Did you recognize that [Address] is visualized as a derived element (refer to the previous section)? You are right. [Address] will have the characteristics of a derived element. However, [Address] is a typical example of a so-called inner element. That is, an overview of addresses does not make sense (nor does a details view for [Address] make sense). After all, a project team does not want to bother about organizations that should share the same [Address] element as soon as they are located at the same address. For these reasons, [Address] should be modeled as an inner derived element.

Because of the far-reaching similarities between an inner element and a property, people consider inner derived elements as ‘expanded’ properties.

Middle element

Consider the following example, where the <has source> relation records for a given requirement, which document was the source.

Such a relation is rather binary. Between a given requirement and a given document, a relation exists or it does not exist (how surprising). However, there is no way to record additional information. Imagine how helpful it would be to hint from which excerpt a requirement was extracted in case of a voluminous document. Therefore, the <has source> relation is abandoned and instead, a middle element is included in the SE model.

In this SE model [Source] is modeled as a middle element between [Requirement] being the origin and [Document] being the target. For a given requirement, a user can 1. create an element of [Source] and 2. Relate this new source to a document in one single operation. Users can also enter page numbers or paragraph numbers in the {Excerpt} property as intended.

Although a middle element enables the recording of additional information compared to a ‘standard’ relation, there are remarkable similarities, especially when it comes to manipulating information:

Relation	Middle element
A relation always has an owner (the element it originates from) and a referenced element (for which the relation is incoming). A relation missing an element on either of its ‘sides’ does not make sense.	A middle element always has an origin and a target. A middle element missing a relation on either of its ‘sides’ does not make sense.
When you delete an element, all relations that originate from this element are deleted as well. Similarly, when you copy an element, all relations originating from the original element are also copied.	When you delete an origin, all its middle elements are also deleted. That is, middle elements are deleted along with their origin. Needless to say, the target relations involved are also deleted. Similarly, when you copy an origin, all its middle elements are also copied. Needless to say, the target relations involved are also copied.
If an element has any incoming relation, you cannot delete this element.	If an element is the target of any middle element, you cannot delete this target.

For this reason, people consider middle elements simply as ‘expanded’ relations.

NB: don’t overapply middle elements just because they bring a lot of user-friendliness. For example, consider the following SE model.

Given a meeting, just by selecting a person, a user can 1. create a new to-do, 2. relate it to the meeting, and 3. assign who is responsible. Although this seems like a lot of user power, it is important to note:

• In this SE model, it is not possible to record a to-do as long as it has not been decided who is responsible.
• Instead of entering a future meeting from scratch, a user may copy a past meeting (about the same subject, at the same location, with the same attendees, etc.). As a result, all to-dos of the original meeting are also copied!
• To ‘clean up’, a user deletes all meetings earlier than two years ago. As a result, all to-dos of these meetings are also deleted. Imagine: the curtains of an office were replaced by purple ones, but we cannot trace back when, in which meeting, by whom, based on which arguments this was decided (remember traceability is a cornerstone of systems engineering).

Thus, similar to what was argued in the previous section, resist the temptation of short-sighted opportunities for usability and stick to a thorough analysis of the semantics.

As a final tip, initially define a middle element as an inner middle element. Middle elements rarely need their own overview or details view (note again the similarity with relations). Later on, an inner middle element can always be toggled to a standard middle element, thereby providing still an overview and a details view.

Takeaways

Derived element

• Stay true to reality and let semantics be the deciding factor, instead of the volatile trade-off between functionalities.
• Thus, model as origin with derived elements, only if a derived element should be deleted along with the deletion of its origin.
• And if a derived element may make sense without an origin, then it should NOT be modeled as a derived element.
• If you know the structure and formatting of a comprehensive property in advance, then model it as an inner(!) derived element instead of a property.

Middle element

• Model as a middle element when the binarity of a ‘standard’ relation falls too short.
• Define a middle element initially as an inner middle element; it can easily be toggled to a standard middle element later on.
• Although a middle element is richer, verify that it should act/behave like a standard relation.
• In specific, if a middle element makes sense without a target or without an origin, it should NOT be modeled as a middle element.
• Once again, stay true to reality and let semantics be the deciding factor, instead of the volatile trade-off between functionalities.