Show only the relationships and thier discription

[Werner Schoenmaekers]

How do I show the list of all these relationsships and theit discription.
I do not need the applicationcomponents or other things.
Just the (ordered) list of relationships.

I included the xmi file

[eadocX Support]

eaDocX can’t do this.
That is because we create documents using the elements, diagrams or Packages, not connectors which link them together.
You might try an Element Report which uses a SQl query to look at the t_connector table.

[Phillip Khaiat]

Actually you can do this easily in eaDocX with an inline profile:

1. Add a table of related elements
2. Pick “Any” relationship type in either direction
3. Add attributes of the relationship, which includes name, description, source & target elements, etc.

[eadocX Support]

Looking this diagram, you seem to have numbered the connectors, which makes me think that perhaps this is a sequence diagram in disguise! If it was a Sequence Diagram, then you can print the Messages which it contains as an ordered list. See the help

[Barrie Treloar]

Actually you can do this easily in eaDocX with an inline profile:

1. Add a table of related elements
2. Pick “Any” relationship type in either direction
3. Add attributes of the relationship, which includes name, description, source & target elements, etc.

I’m needing to do the same thing, as the OP.

For example: On a deployment diagram trying to capture details about the links between nodes to indicate link protocols, capacity, link speeds, estimated new traffic, etc.

What @Pkhaiat is suggesting will only document the source and target elements of the relationshop and not the details of the relationship itself.

You might try an Element Report which uses a SQl query to look at the t_connector table.

Is there any guidance on learning more about the table structure?
I’m reluctant to learn that black magic…

Which leads to another question…

Perhaps what I am trying to model is not the best way to model it.

Is there any guidance anywhere on this stuff?
This issue fails in the gaps between EA and eaDocX.

Someone else’s opinion would be valuable.

Cheers

[Heather Wallace]

As far as the table structure goes I can recommend “Inside Enterprise Architect” by Thomas Killian, available from https://leanpub.com/InsideEA.

It was recommended to me and I’ve found it to be a really valuable resource. It can also be useful to browse the data in a database management tool to really understand how your data is held. I tend to use MS Access (needs to be 2010 or earlier for EA10 – don’t know about later EA versions) to look at a local copy of the project. I change the .eap extension to .mdb and can then use the linked table manager in MS Access to find the project file and link to all the tables. Only a few tables tend to be populated, so it is easy to get to grips with. There are a few complications, such as the handling of stereotypes – watch out for the t_xref table!

Heather

[eadocX Support]

eaDocX will let you print any attribute of the connector between two elements, as well as any tagged value of that connector. But you can’t document a connector on its own, only in the context of the elements at one of its ends.
If you think this is what you want to do, then this is often because what you have modeled as a connector is better modeled as an element.
For example, if you wanted to model a telecoms connection between two boxes, it maybe feels natural to make that connection into an EA Connector.
..but I’d always make it an Element, so that it can have its own independent existence, be put on diagrams etc.

[Barrie Treloar]

eaDocX will let you print any attribute of the connector between two elements, as well as any tagged value of that connector. But you can’t document a connector on its own, only in the context of the elements at one of its ends.
If you think this is what you want to do, then this is often because what you have modeled as a connector is better modeled as an element.
For example, if you wanted to model a telecoms connection between two boxes, it maybe feels natural to make that connection into an EA Connector.
..but I’d always make it an Element, so that it can have its own independent existence, be put on diagrams etc.

What my current document has is a table documenting the interactions between components:

ID | Component A | Component B | Interaction
IN-001 | Website | Web Server | Public interacts with website to do blah. Expected Load: X per day, Peak Load: Y per day
IN-002 | …

At the moment I am not challenging what people are putting into the document – only trying to automate its creation from Sparx.

I’m not keen on the table format as this make the interesting bit of information (namely the Interaction) all squished into less than 25% of the table width.

However at the moment I dont even know how to go about getting eaDocX to generate the information. Can you describe how I can document the connector? All I can get work out is element -> connector -> element. I can’t stop at the connector to get its properties.

I’d be happy to consider putting in an element in for documentation purposes, but it will uglify the diagrams.

[Author]

Posts