Design Data Link (DDL)

With the Design Data Links, Design Data Objects are networked with each other, e.g. dependencies, assignments, or refinements.

Design data links are more than just links between design data objects. In RePoSyD, all links are directed, i.e. the start and end points are defined , they are typed (semantics) and have their own attributes, e.g. status information.

Example: Requirement - Component

It cannot be determined which of the Design Data Objects is the start or end point.

Example: Requirement → Component

In contrast to the upper example, the start and end point of the relation can be determined here. In the example shownb above, it is still unclear how the two engineering elements relate to each other. Furthermore, multiple relationships between engineering elements cannot be mapped. E.g. the vertical and horizontal traceability of requirements.

• Requirement → Requirement: vertical - requirement is refined by requirements
• Requirement → Requirement: horizontal - requirement is comparable with other requirements

Example: Requirement → specifies → Component

Here, both the start and end point, as well as the meaning of the relationship between the Design Data Objects can be determined. Likewise, multiple link can be mapped.

• Requirement → derives → Requirement: vertical - requirement is refined by requirements
• Requirement → traces to → Requirement: horizontal - requirement is comparable with other requirements

Forward and Reverse Link

Each connection between two types of construction data objects is defined by a forward and backward relation. An example of this is the parent-child relationship of objects in a hierarchy.

• Parent → Child: Requirement → is refines by one or more → Requirements
• Child → Parent: Requirement → refines one → Requirement

• Requirement → is refined by one or more → Requirements
• Requirement → refines one → Requirement

Where the forward or reverse direction of the relationship depends on the respective definition of the link.

For each connection between two Design Data Objects, the cardinality of the relationship is defined. It defines whether a Design Data Object can be related to only one or more other Design Data Objects.

• Requirement → is refines by one or more → Requirements
• Requirement → refines one → Requirement