Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: jthillmn on February 19, 2020, 11:23:02 am
-
Is it possible to include a Relationship Matrix when generating documentation for a model? As they appear to be dynamically generated and printable only from within the "Options|Matrix", I'm assuming they cannot be part of any model documentation generated. Am I correct in that understanding?
Thanks...Jim
-
You can include them, but they are generated as an (ugly) image that if often barely readable, or not readable at all.
We usually export that type of information using an SQL Fragment.
Geert
-
You can include them, but they are generated as an (ugly) image that if often barely readable, or not readable at all.
We usually export that type of information using an SQL Fragment.
Geert
As a proper tabular matrix? Or using a less structure format?
-
You can include them, but they are generated as an (ugly) image that if often barely readable, or not readable at all.
We usually export that type of information using an SQL Fragment.
Geert
As a proper tabular matrix? Or using a less structure format?
No, not a matrix format, but usually a table with (at least) two columns. One for the source, and one for the target.
Depending on the requirements I sometimes
- only include the linked items (inner join)
- include all source items but only linked target items (left join)
- include all source items, all target items and all the links between them (full outer join)
This table then contains the same information as the relationship matrix, only in a different format.
Making a "real" relationship matrix table is difficult because of the variable amount of columns.
The only option I see would be a document script (where you craft the RTF code yourself)
It also doesn't really work in documents as it tends to get too wide pretty quickly.
Geert
-
Making a "real" relationship matrix table is difficult because of the variable amount of columns.
The only option I see would be a document script (where you craft the RTF code yourself)
It also doesn't really work in documents as it tends to get too wide pretty quickly.
I recently did something similar, a RACI matrix with a variable number of columns (2-11) which also splits into multiple tables if the number of columns exceeds the maximum, using the DocumentGenerator and XML custom data.
10 header templates, 10 row templates, and some 250 lines of script code just for the structures, not counting data extraction and content creation.
Clunk and ugly, but it does work. 8)
/Uffe
-
(declared interest - I'm the author of the tool mentioned below)
eaDocX can do this, and at the same time add additional header rows and columns, and add conditional formatting. The example we use is a RACI matrix, where eaDocX maps the string 'Responsible' to a simple 'R', and adds appropriate color. So the model stays the same. It can also print a matrix in a more linear format (see the eaDocX help for an example) where the matrix has too much data to appear in a readable page.
-
Thank you all for your responses to this question. It's appreciated.
Geert, would it be possible for you to share the SQL you include in your SQL Fragment?
Regards...Jim
-
Jim,
Here's an example of such a query that show the activities in a BPMN diagram and the RASCI relation to the BPMN PartnerRoles
select bpa.name as Activity,
r.RoleName, r.RASCI
, CASE WHEN r.RASCI = 'R' THEN r.RASCI ELSE NULL END as R
, CASE WHEN r.RASCI = 'A' THEN r.RASCI ELSE NULL END as A
, CASE WHEN r.RASCI = 'S' THEN r.RASCI ELSE NULL END as S
, CASE WHEN r.RASCI = 'C' THEN r.RASCI ELSE NULL END as C
, CASE WHEN r.RASCI = 'I' THEN r.RASCI ELSE NULL END as I
from t_object bp
left join t_object pl on pl.ParentID = bp.Object_ID
and pl.Stereotype = 'Pool'
left join t_object ln on ln.ParentID in (pl.Object_ID, bp.Object_ID)
and ln.Stereotype = 'Lane'
inner join t_object bpa on bpa.ParentID in (ln.Object_ID, pl.Object_ID, bp.Object_ID)
and bpa.Stereotype = 'Activity'
left join t_objectproperties tv on tv.Object_ID = bpa.Object_ID
and tv.Property = 'calledActivityRef'
left join t_object ca on ca.ea_guid = tv.Value
left join
(select c.Start_Object_ID, ro.Name as RoleName, tv.VALUE as RASCI from t_connector c
inner join t_object ro on ro.Object_ID = c.End_Object_ID
and ro.Stereotype = 'PartnerRole'
left join t_connectortag tv on tv.ElementID = c.Connector_ID
and tv.Property = 'RA(S)CI'
where c.Stereotype = 'trace') r on r.Start_Object_ID = bpa.Object_ID
left join t_diagramobjects do on do.Object_ID = bpa.Object_ID
left join t_diagram d on d.Diagram_ID = do.Diagram_ID
and d.ParentID = bp.Object_ID
where bp.Object_ID = #OBJECTID#
order by do.RectLeft, do.RectTop desc, bpa.Name
, CASE WHEN r.RASCI = 'R' THEN 1
WHEN r.RASCI = 'A' THEN 2
WHEN r.RASCI = 'S' THEN 3
WHEN r.RASCI = 'C' THEN 4
WHEN r.RASCI = 'I' THEN 5 ENDIn this case it's a left join situation. We show all Activities, even the ones that don't have a linked role, but we only show the roles linked to an Activity.
In EA we manage this information with a Relationship matrix (with RASCI overlay), but in the document we show it like this.
Geert
-
Thank you, Geert.
-
An alternative option that I have used is an intermediate step via a spreadsheet. Roughly this was the process:
1. Export the matrix as CSV
2. Open in Excel
3. Create a second sheet to provide a nice presentation format, referencing the CSV export sheet. You might want to do things like rotate the top row text. This included changing the symbol used to represent a connection (I forget what the symbol is in CSV but I think I used an arrow in the second sheet)
4. Save in Excel spreadsheet format
5. Copy and paste the second sheet into Word
To update, re-generate the CSV, copy and paste the data into the excel file and the second sheet automatically updates through its links to the first sheet. Copy and paste that again into the Word doc. I didn't try, but you might be able to automatically embed the just the second sheet into the master document.
In step 3 you can optionally combine the name with the Alias (if that is important to you) by separately exporting names and aliases and using VLOOKUPs to match everything together.
-
Late discovery - easily implemented, approach is to include the "Relationship Matrix" in the "Package" section. That prints out a "Matrix Specification" quite nicely.
-
Late discovery - easily implemented, the approach is to include the "Relationship Matrix" in the "Package" section. That prints out a "Matrix Specification" quite nicely.
That's cool! Do you know how LARGE matrices are handled?
Paolo
-
They size nicely. Massive matrices, although fitting on the page, can yield text so small as to be unreadable.
-
They size nicely. Massive matrices, although fitting on the page, can yield text so small as to be unreadable.
That's been my experience just printing the Matrices onto a single page. Are you saying they split over pages automatically etc?
Paolo
-
Sorry for the late reply, Paolo.
My experience has shown that the entire matrix fit onto a single page to an extent that it was unreadable; even when zooming in on the resulting .rtf / .doc generated. What it would do on a really, really, really large matrix...I can't say.