Listing the "visible" attributes in a diagram.

[stevesavage]

For my projects I typically have a domain model with classes that define the overall data-set being created/modified/used by a set of business activities.
I have a diagram showing a BPMN activity + the one or more classes it's linked to, and then use the feature visibility so only the attributes that are relevant to the activity are visible.

In addition to this diagram, I want to list these "visible" attributes and their properties within my reports.  (at the moment people have to look at the diagram, and then find the info in the domain model report)

After a bit of searching I found how and where Sparx EA stores this information in the DB.
I had hoped it would be something simple in in the t_diagramobjects or t_xref.

Instead the list of visible or invisible attributes are in t_diagram.StyleEx
SPL=S_2B7534=E8B177,838277:S_6CC0D7=32C749,671377,4517EB:

Where
S_2B7534 = the element with the GUID {2B753453-3F2D-4a25-8D5D-DA8FAF0E4674}
S_6CC0D7 = the element with the GUID {6CC0D72C-086B-45e3-B6C7-A70D0AC8984A}

E8B177,838277 = the attributes under S_2B7534 that are hidden
32C749,671377,4517EB = the attributes under S_6CC0D7 that are visible

Why only the first 6 chars of the GUIDs are used, don't know, but hopefully will not cause issues.

To determine if the attributes listed are hidden or visible you have to look in t_diagramobjects
For Object_ID = 2 = {2B753453-3F2D-4a25-8D5D-DA8FAF0E4674} = S_2B7534 : t_diagramobjects.ObjectStyle, AttCustom=0
For Object_ID = 3 = {6CC0D72C-086B-45e3-B6C7-A70D0AC8984A} = S_6CC0D7 : t_diagramobjects.ObjectStyle, AttCustom=1

My current idea is to create a template fragment that calls a script that returns the recordset I need.
But before I go that route, I was wondering if anyone had created an SQL query that could actually tie all this mess together?

[Geert Bellekens]

I haven't, I would also go the script route, seems a lot easier then trying to do that in SQL.

Geert

PS. I don't particularly like the idea of putting relevant information in diagrams, and especially not whether or not an attribute is visible on a certain diagram or not. For similar purposes I use the schema composer combined with my addin EA Message Composer to create a subset of data model

[stevesavage]

Now that I know how the information is stored I've been thinking the same thing.

At the moment my domain model is a class diagram, where each attribute is defined by an element.

E.g. The Element "NOx Emission Intensity" defines what NOx Emission Intensity is, is stereotyped as a DD_Number (data dictionary number), and has tagged values for basic data quality rule such as min precision, max precision etc.

The Class "Test Result" has the Attribute "NOx Emission Intensity", the Attribute references the Element "NOx Emission Intensity" as it's data type.

I have a Business Activity for updating the test.   At the moment the business activity is linked to the Class "Test Result" with the only relevant Attributes visible.
I think instead I'll copy the relevant Attributes so they appear as attributes of the Business Activity.  All copies will point to the same Element for their definition, so this could work.

Will experiment.

[Geert Bellekens]

It's not so much how it is stored that bothers me, but the fact that the information is only present in diagram.

One of the first thing I tell people when I'm giving a course is that there is a difference between diagramming (like in Visio) and modelling (like in EA).
I then tell them that with modelling I can delete all of my diagrams and still have all the information; because a diagram is merely a view on the model, and of course a handy tool to communicate a part of the model amongst us humans who are not really good at reading a model without diagrams (as opposed to computer programs, they don't need the diagrams at all)

Geert

[Paolo F Cantoni]

It's not so much how it is stored that bothers me, but the fact that the information is only present in diagram.

One of the first thing I tell people when I'm giving a course is that there is a difference between diagramming (like in Visio) and modelling (like in EA).
I then tell them that with modelling I can delete all of my diagrams and still have all the information; because a diagram is merely a view on the model, and of course a handy tool to communicate a part of the model amongst us humans who are not really good at reading a model without diagrams (as opposed to computer programs, they don't need the diagrams at all)

Geert

Absolutely agree with you on Diagram vs Model (and I also add "Picture" (jpg etc))

Now, with regard to SteveSavage's original issue.  I think there's a danger of conflating two related, but separate, issues:
Without a doubt, the specification that a specific Feature (in this case, attribute) should be renderd as visible on a particular diagram is a per-diagram property. 
The decision as to what the set of those features is may be held elsewhere.  Specifically, in this case, it would seem to be a property of the relationship between the Activity and the Class. 
Over the decades, I've come to the realization that a lot of such metadata should be held in the relationships and that tools don't support this idea natively (at least, I don't know of any).
My suggestion is to store the list of "applicable" attributes in the relationship and then, on a per-diagram basis, interrogate the list from all applicable relationships into the class and set the visibility of the attributes as the union of the the applicability sets.

HTH,
Paolo

[stevesavage]

It's not so much how it is stored that bothers me, but the fact that the information is only present in diagram.

One of the first thing I tell people when I'm giving a course is that there is a difference between diagramming (like in Visio) and modelling (like in EA).
I then tell them that with modelling I can delete all of my diagrams and still have all the information; because a diagram is merely a view on the model, and of course a handy tool to communicate a part of the model amongst us humans who are not really good at reading a model without diagrams (as opposed to computer programs, they don't need the diagrams at all)

Geert

You're right Geert, I have used the visibility approach mainly when I need to create a viewpoint for a specific report where I only wanted to include a subset of the relationships.

But I realize now, in this case (Business Activities -> Class.Attribute) I do want to explicitly model the relationship.

So what's the best approach?

I can see two options:

• A connector + link to element feature to link the Business Activity to each and every Class.Attribute
• Copy the Attributes to the Business Activity

The first option is probably the most "pure", but

• we all know that Sparx stores the GUID's for the attributes in an annoying way, so reports that need to list the associated attributes will need a custom query (doable).
• traceability only shows to the Class, not to the Class.Attribute, but Element.Browser does show the relationship to the Attributes under Linked Features

The second option only works because of what I mentioned earlier in the discussion, that all the copies of an attribute point to the same "classifier" element. 

• this would explicitly list the attributes under the activity
• but isn't as clear if the activity needs to link to multiple classes (I think this is the deal breaker).

I'm now leaning towards using the first option.

I just wish I could do ctrl+drag the attributes from the class to the activity and be prompted:

• Link target to Source.Attributes
• Copy Attributes and Link to Source.Attributes

The first option would simply link the Business Activity to the set of Class.Attributes instead of me having to create the links one at a time using Link Element Feature.

The second option would be more useful for mapping attributes explicitly to other attibutes

Geert, I know you have made several interface addons, have you created something to simplify linking to specific attributes?

[Geert Bellekens]

Hi Steve,

I'm currently working on a mapping tool that will probably make this easier for you.
The project is at the stage that I have now a list of sponsors and I'm getting them to agree on a list of requirements. I'm hoping to have a first version ready before the end of the year.
For more information see http://bellekens.com/2016/09/22/ea-mapping-tool-the-next-steps/

Another tool I mentioned is the EA Message composer which will allow you to create a subset of a model, selecting classes, attributes and associations you are interested in. The subset model keep complete traceability to the original model. That might be useful in your situation as well.

Geert

[stevesavage]

Hi Steve,

I'm currently working on a mapping tool that will probably make this easier for you.
The project is at the stage that I have now a list of sponsors and I'm getting them to agree on a list of requirements. I'm hoping to have a first version ready before the end of the year.
For more information see http://bellekens.com/2016/09/22/ea-mapping-tool-the-next-steps/

Another tool I mentioned is the EA Message composer which will allow you to create a subset of a model, selecting classes, attributes and associations you are interested in. The subset model keep complete traceability to the original model. That might be useful in your situation as well.

Geert

Thanks Geert, will take a look.  For now I created a script that links the Business Activity to all the Attributes in the Class, I think just delete the ones I don't want.   E.g. Select Activity, run script, prompted to select one or more classes, prompted to enter the type and stereo type of the connector you want, then script links all the attributes.  I then delete the ones I don't want.   Not the best, but still manually faster than creating them one at a time.

[Glassboy]

Over the decades, I've come to the realization that a lot of such metadata should be held in the relationships and that tools don't support this idea natively (at least, I don't know of any).

Because most tools work on top of relational databases and relational concepts subconsciously influence the design.  I suspect if EA was built on a graph database, we'd be seeing more of the wiki functionality that people seem to desire.

[Paolo F Cantoni]

Over the decades, I've come to the realization that a lot of such metadata should be held in the relationships and that tools don't support this idea natively (at least, I don't know of any).

Because most tools work on top of relational databases and relational concepts subconsciously influence the design.  I suspect if EA was built on a graph database, we'd be seeing more of the wiki functionality that people seem to desire.

Don't think the relational model is the problem.  It's a conceptualisation issue.  People just didn't think of it.  We can implement what we want on top of EA's DB design.

I didn't get it until I'd read Object Oriented Software Construction II by Bertrand Meyer - he discusses how specialization / generalization is actually potentially more complex that normally conceived and implemented.  That's when it occurred to me that the detail (which features, we directly available, which overridden, which removed etc.) in any specific generalization were properties of THAT specific generalization.  Consequently the ONLY place that they could be held was against the relationship itself.  That way, the impact of any changes in the base or child class could be managed properly.

Paolo

[wverhoef]

Hi

Sorry for posting something related to the start of a pretty old thread but this is the closest question I've found to what I'm trying to do, so harking back to the beginning of this thread.....I'm trying to create a SQL query to report all elements that appear in a diagram.  The subsequent discussion in this thread notwithstanding, our team finds it very useful to be able to generate diagrams based on discussions of requirements or on questions of what classes & attributes are present in the model to support a given use case.  We use tags to officially document/track what is part of a given use case, but it would really be helpful to run a report on these diagrams we're dynamically generating on a frequent basis.  And we're all pretty good at SQL so we're sticking with that cuz its easy to tweak the query.

If I understand the comments correctly, joining the list of attributes referenced for the SPL variable(?) in t_diagram.StyleEx with the AttCustom in t_diagramobjects.ObjectStyle is supposed to show us what attributes are hidden (AttCustom=0) or displayed (AttCustom=1).  However, when I run a query against a diagram with...
1) a single class with a few attributes where all attributes are displayed and compare the AttCustom value against...
2) the same diagram and class with all attributes hidden via the Feature and Compartment Visibility > Attribute Visibility > All=unchecked, and against...
3) the same diagram and class with some attributes hidden, some displayed via Feature and Compartment Visibility > Attribute Visibility > Custom,
... it turns out they all have AttCustom=0.  No matter how the attributes are hidden.  So, I'm questioning if I have that right. 

How and where exactly does the database capture the various ways to hide and display attributes in diagrams (in all the various combinations)?  My query is currently showing the right attributes when they are mixed displayed and hidden, but it's not showing all attributes when nothing is hidden or when all are hidden, so I'm working on that while awaiting guidance.

Thanks for any feedback you can give!
W.

[Geert Bellekens]

Hi,

I guess it's going to take some experimenting to get it all right.

The diagram has a setting to show or hide all attributes.
The diagramObject keeps track of which attributes to hide or show.

Geert

[wverhoef]

Hi all,

I was able to figure it out eventually and here's the query I came up with (see below). It turns out that the AttCustom variable can be set to 0 or 1 and that flips the meaning of whether the attributes listed in the t_diagram.StyleEx column are hidden or shown.  Sure would be great if Sparx would provide a document so users could figure out how to parse t_diagram.StyleEx and t_diagrambbjects.ObjectStyle.  I never try to change the values there and wouldn't mind if they changed the rules, if they would just share the meaning of the stuff in there.  Using the <Search Term> variable works sporadically at best for my semi-old copy of EA, so I've been substituting the actual diagram name before running the query.  And we're going to have to figure out how to display the Description (notes fields) in a way that eliminates our newlines and commas (separate post).  For what it's worth, here's the query - hope someone finds it useful:

SELECT
t_diagram.name AS [DIAGRAM NAME],
t_object.name AS [CLASS NAME],
t_attribute.name AS [ATTRIBUTE NAME],
t_attribute.type AS [DATA TYPE],
t_attribute.lowerbound+'..'+t_attribute.upperbound AS [CARDINALITY],
t_attribute.Notes AS [DESCRIPTION]
FROM ((t_diagramobjects
INNER JOIN t_object ON t_object.Object_ID = t_diagramobjects.Object_ID)
INNER JOIN t_diagram ON t_diagram.Diagram_ID = t_diagramobjects.Diagram_ID)
INNER JOIN t_attribute ON t_attribute.Object_ID = t_object.Object_ID
WHERE t_diagram.name = '<Search Term>'
AND t_object.Object_Type = 'Class'
AND (
      (
       (INSTR(t_diagram.StyleEx,MID(t_object.ea_guid,2,6)) = 0)
   AND (INSTR(t_diagramobjects.ObjectStyle,'AttPro=0;AttPri=0;AttPub=0;AttPkg=0') = 0)
   AND (INSTR(t_diagramobjects.ObjectStyle,'AttCustom=0') = 0)
   AND "COMMENT:  this set brings back attributes for classes where nothing is hidden."
     )
   OR (
       (INSTR(t_diagramobjects.ObjectStyle,'AttPro=0;AttPri=0;AttPub=0;AttPkg=0') > 0)     
    AND (INSTR(t_diagram.StyleEx,MID('S_'+t_object.ea_guid,2,6)) > 0)
    AND (INSTR(t_diagram.StyleEx,MID(t_attribute.ea_guid,2,6)) = 0)
   AND "COMMENT:  this set evaluates to false so that it excludes attributes for classes where all attributes are hidden."
     )   
   OR (
        (INSTR(t_diagram.StyleEx,MID(t_attribute.ea_guid,2,6)) = 0)     
    AND (INSTR(t_diagram.StyleEx,MID(t_object.ea_guid,2,6)) > 0)
   AND (INSTR(t_diagramobjects.ObjectStyle,'AttCustom=0') > 0)
   AND "COMMENT:  this set shows unhidden attributes, whether hidden ones are selected individually or using the custom All button."
     )
   OR (
        (INSTR(t_diagram.StyleEx,MID(t_attribute.ea_guid,2,6)) > 0)     
    AND (INSTR(t_diagram.StyleEx,MID(t_object.ea_guid,2,6)) > 0)
   AND (INSTR(t_diagramobjects.ObjectStyle,'AttCustom=1') > 0)
   AND "COMMENT:  this set shows unhidden attributes, whether hidden ones are selected individually or using the custom All button."
     )
   )
UNION ALL
SELECT
t_diagram.name AS [DIAGRAM NAME],
t_object.name AS [CLASS NAME],
'' AS [ATTRIBUTE NAME],
'' AS [DATA TYPE],
'' AS [CARDINALITY],
t_object.Note AS [DESCRIPTION]
FROM ((t_diagramobjects
INNER JOIN t_object ON t_object.Object_ID = t_diagramobjects.Object_ID)
INNER JOIN t_diagram ON t_diagram.Diagram_ID = t_diagramobjects.Diagram_ID)
WHERE t_diagram.name = '<Search Term>'
AND t_object.Object_Type = 'Class'
ORDER BY 1, 2, 3;

[Richard Freggi]

BRILLIANT!  Thank you wverhoef you saved me days of work and an ulcer or three.

Your query works perfectly.

Here's the version for Firebird (just the filter condition):

Code: [Select]

-- Filter out attributes hidden via EA's Features and Properties menu: custom visibility
AND (--List attributes of classes where nothing is hidden
(
(POSITION(SUBSTRING(t_object.ea_guid FROM 2 FOR 6) IN t_diagram.StyleEx) = 0)
AND (POSITION('AttPro=0;AttPri=0;AttPub=0;AttPkg=0' IN t_diagramobjects.ObjectStyle) = 0)
AND (POSITION('AttCustom=0' IN t_diagramobjects.ObjectStyle) = 0)
)
OR --Ensure no listing of attributes of classes where all attributes are hidden

(
    (POSITION('AttPro=0;AttPri=0;AttPub=0;AttPkg=0' IN t_diagramobjects.ObjectStyle) > 0)     
    AND (POSITION(SUBSTRING('S_' || t_object.ea_guid FROM 2 FOR 6) IN t_diagram.StyleEx) > 0)
    AND (POSITION(SUBSTRING(t_attribute.ea_guid FROM 2 FOR 6) IN t_diagram.StyleEx) = 0)
)   
OR----List attributes of classes hidden using the SHow visibility - custom button

(
(POSITION(SUBSTRING(t_attribute.ea_guid FROM 2 FOR 6) IN t_diagram.StyleEx) = 0)     
AND (POSITION(SUBSTRING(t_object.ea_guid FROM 2 FOR 6) IN t_diagram.StyleEx) > 0)
AND (POSITION('AttCustom=0' IN t_diagramobjects.ObjectStyle) > 0)
)

OR (--List unhidden attributes
(POSITION(SUBSTRING(t_attribute.ea_guid FROM 2 FOR 6) IN t_diagram.StyleEx) > 0)     
AND (POSITION(SUBSTRING(t_object.ea_guid FROM 2 FOR 6) IN t_diagram.StyleEx) > 0)
AND (POSITION('AttCustom=1' IN t_diagramobjects.ObjectStyle) > 0)
)
)

-- End filtering of hidden attributes