Structuring documents using Relationships
You will usually want to specify that the related data is a simple attribute (Formatting Inline LINK or as a column in a Table LINK) or as a separate relationship table. However, by adding a Relationship Element LINK to the formatting of another element, the related element will print out in whatever way the Profile says it should print. This may seem like an unnecessary option, but it allows you to print your document entirely based on the relationships between elements, and not on the package structure.
Example
Suppose we have a model with Components, Use Cases and Requirements, linked like this:
The Package structure for these elements is:
This is a standard way to store these elements in EA.
The ‘normal’ structure (i.e. eaDocX following the EA model structure) would be:
However, an alternate structure for our document could be to describe each Component, including all its use cases and all the associated Requirements for each use case, and do this for all the components (i.e. to look like this):
We could make the EA structure follow this pattern, but that might stop another document from printing correctly. Or, we might not be allowed to make these kinds of changes.
Instead, we can use relationships, rather than the package structure, to determine the structure of our document.
When we print Component elements, we can configure them to print all the “Use case” elements related to them via a’ Realization’ connection:
Similarly, we can tell Use Cases to print all their related ‘Requirement’ elements connected with a ‘Realization’ relationship:
We can do this with high precision by having different formatting for each element type & stereotype. We can be very specific about which relationships we want to navigate using the relationship type (Dependency, Realization, Association, etc.) and even the name & stereotype of those relationships.
This approach works very well when we can ensure that everyone working on the model follows the same modeling standards. (If they aren’t, eaDocX documents will soon show where there are model inconsistencies.)
Access
missing