Unusual customer requirement: possible to hide the name of Component attributes?

[Richard Freggi]

I have a conceptual level component diagram.  Each component shows the key data managed by that component, as follows: Add attributes to the component, give each attribute a meaningless name (a sequential number), assign a datatype to each attribute.  The datatype is selected from the conceptual level class diagram of the domain.  In other words, the business entities of the domain are shown mapped into the conceptual level solution components.
Customer would like to hide the meaningless name (sequential number) from the diagram and only see the datatypes.  But the diagram options (double click on diagram - Features) are only to show attribute names only, or attribute name and type.  There is no option to show attribute type only.  Is there a workaround to do this?  Thanks!

[qwerty]

Maybe a shape script could do this with some sort of print("#addin:myAddIn#")
No idea how that string will appear with a newline separated list of the types.

q.

[Modesto Vega]

I have a conceptual level component diagram.  Each component shows the key data managed by that component, as follows: Add attributes to the component, give each attribute a meaningless name (a sequential number), assign a datatype to each attribute.  The datatype is selected from the conceptual level class diagram of the domain.  In other words, the business entities of the domain are shown mapped into the conceptual level solution components.
Customer would like to hide the meaningless name (sequential number) from the diagram and only see the datatypes.  But the diagram options (double click on diagram - Features) are only to show attribute names only, or attribute name and type.  There is no option to show attribute type only.  Is there a workaround to do this?  Thanks!

This is one very unusual, so unusual that I would dare to ask why, which contradicts an approach I suggested elsewhere in the forum.
Does the customer understand that a list of data types is likely to be meaningless and add very little information?

Qwerty is right, a shape script may be the only way to do this.

[Richard Freggi]

In this conceptual level system architecture (component diagram):

The list of data types is key.  Because the data types are the key business concepts (semantic data dictionary = conceptual level classes) of their business domain.  So the types are not int, string etc... they are "Demand Plan", "Manufacturing Order", "Shipping Document" etc. etc.

The names of the attributes are irrelevant (we can reuse the conceptual datatypes over and over by referring to the conceptual class diagram, but we cannot reuse the names, they are just text without semantics).  That's why the customer wants to hide them, they are just clutter.

[Paolo F Cantoni]

In this conceptual level system architecture (component diagram):

The list of data types is key.  Because the data types are the key business concepts (semantic data dictionary = conceptual level classes) of their business domain.  So the types are not int, string etc... they are "Demand Plan", "Manufacturing Order", "Shipping Document" etc. etc.

The names of the attributes are irrelevant (we can reuse the conceptual datatypes over and over by referring to the conceptual class diagram, but we cannot reuse the names, they are just text without semantics).  That's why the customer wants to hide them, they are just clutter.

Actually, we might have a similar need, for (essentially) the same reason.  Once you get to the point where the datatypes refer to domain items in the model you need to be able to suppress the Feature name (if required).

Paolo

[Modesto Vega]

In this conceptual level system architecture (component diagram):

The list of data types is key.  Because the data types are the key business concepts (semantic data dictionary = conceptual level classes) of their business domain.  So the types are not int, string etc... they are "Demand Plan", "Manufacturing Order", "Shipping Document" etc. etc.

The names of the attributes are irrelevant (we can reuse the conceptual datatypes over and over by referring to the conceptual class diagram, but we cannot reuse the names, they are just text without semantics).  That's why the customer wants to hide them, they are just clutter.

It is good I asked.

Are those really data types? To me they look like business objects/conceptual data entities or elements in an ontology. I would model them as attributeless classes and not as attributes.

Of course, I may adjust this answer depending on whether you are using this approach to model a hierarchical electronic data exchange messaging structure - e.g., EDI or XML messages.

[Richard Freggi]

I just need the conceptual level classes to be associated with the Component, and to show them inside the component in the conceptual level component diagram.  afaik listing them as attribute data types of the component is the only way to do this.

[Modesto Vega]

I just need the conceptual level classes to be associated with the Component, and to show them inside the component in the conceptual level component diagram.  afaik listing them as attribute data types of the component is the only way to do this.

I must admit that the more I read about your requirement the less I understanding it, but it has been a long day.

Have you modelled the conceptual level classes as Classes in Sparx EA? Have you modelled your component as a Component in Sparx?

Assuming the answer to these 2 questions is Yes: what are you trying to represent by having the classes inside the component? Why haven’t you use a Package instead of a Component?