How To link element to attribute of other element

[CJ]

G'day folks,

I'm using EA to document the database requirements (and layout, etc.) of screens.  Those screens have fields that show values selected from table columns (aka attributes).

If I make changes to some table column, then that may have an impact on fields such that the fields require some changes to their properties.

Anybody can think of a good way to create a link between screen fields and table columns (aka attributes) such that I can use the Relationship Matrix to manage the impact of database table column changes on screen fields that display values from those columns?

This question relates to one I posted earlier: http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1095189133;start=7#7.

I'm hoping that I've described a better scenario for my problem, in the hopes of generating some more (much appreciated) ideas.

[thomaskilian]

CJ,
I was just about to link you to your mentioned post  

Before giving a sho(r)t answer I want to know why and when the columns will change. Is it during design phase or is it "real life demand"? Depending on this, the answer will be completely different.

[CJ]

G'day,

This would apply to construction phase during development and to the maintenance cycle too.

For example, say the size of a database column increases.  I'd like to quickly identify all those (already created and tested/signed-off) screen data fields that need to have their "size" properties increased.

[thomaskilian]

I see what you mean. The only way you could manage this would be to introduce a control that you link in between GUI element and table (aka column). I do not see any direct way because you cant create links to class operations directly. You only see the GUI element and the table in the relationship matrix. Instead of the control I could also think of a requirement being linked in between (also describing the reason for the size change).

[mchiuminatto]

CJ

I'm faced to the same problem. A client include as sumplementary specification a mapping between GUI controls and database fields. That mapping is the input for an automated web application generation tool. Well I keep on thinking how to do it with EA, meanwhile I document it manually.

The first "solution" that came to my mind was to model the database fields as individual objects and then establish a trace relation from a Screen control to a database field object. Finally I didn't try it. I think  is less effort consuming to do it manually.

[Bruno.Cossi]

Hi,

how about linking the GUIElement to the Table and on the association select the appropriate column as a Role?
It is not perfect as the column name does not show up in the relationship matrix, but one can easily look it up.

What do you think?

Bruno

[thomaskilian]

Bruno,
I also had this in mind and would probably be a good idea, if the role name could be displayed in the relations window. If Sparx could add this feature (configurable columns for the relations window) it would really help.

[CJ]

Thanks for the feedback, folks.

Here's what I've found works the best (for me) so far:

In my domain model,  I model everything as distinct elements (currently using class elements).  So say we have students and they have names, I create a "student" class, a "student name" class.

So, anything (db table, gui control, report field, etc.) that <<depends>> on the definition of "student name" can be discovered via relationship matrix.

Although it's nice to have attributes "externalized" as their own elements, I'm still trying to decide whether or not the effort has any value other than that and the matrix.

added ->> Here's a thought:  would externalizing attributes this way help understand the domain better?

[Bruno.Cossi]

Hi Thomas,

that certainly would help... time for another communal action? :-)

Bruno

Bruno,
I also had this in mind and would probably be a good idea, if the role name could be displayed in the relations window. If Sparx could add this feature (configurable columns for the relations window) it would really help.

[Bruno.Cossi]

Hi CJ,

I went down that route as well, one of the problems though was that I couldn't use reverse/forward engineering of the tables.

Bruno

Thanks for the feedback, folks.

Here's what I've found works the best (for me) so far:

In my domain model,  I model everything as distinct elements (currently using class elements).  So say we have students and they have names, I create a "student" class, a "student name" class.

So, anything (db table, gui control, report field, etc.) that <<depends>> on the definition of "student name" can be discovered via relationship matrix.

Although it's nice to have attributes "externalized" as their own elements, I'm still trying to decide whether or not the effort has any value other than that and the matrix.

added ->> Here's a thought:  would externalizing attributes this way help understand the domain better?

[CJ]

G'day Bruno,

I'm thinking that the domain model and the database model are separate and distinct.  The database model (and the gui elements + reports) traces back to the domain model.

So the STUDENT database table would trace back to the "student" element for the general definition of what a student is, but then would also trace back to the "student name" element for the definition of student name.

Unfortunately, the relationship matrix wouldn't be able to tell me what database columns are affected by a change to "student name", but at least I could identify all of the affected database tables.

aside --> The domain model's setup would make for a good data dictionary.  Each element that represents an attribute could define standards such as naming conventions, etc.

[Bruno.Cossi]

Hi CJ,

I see what you mean and I can see the advantages of that. I still would like if the relationship matrix were more flexible, but your solution certainly does the job (have been playing around with it a bit this morning, it is a bit of a hassle, but it does make sense).

Thanks,
Bruno

G'day Bruno,

I'm thinking that the domain model and the database model are separate and distinct.  The database model (and the gui elements + reports) traces back to the domain model.

So the STUDENT database table would trace back to the "student" element for the general definition of what a student is, but then would also trace back to the "student name" element for the definition of student name.

Unfortunately, the relationship matrix wouldn't be able to tell me what database columns are affected by a change to "student name", but at least I could identify all of the affected database tables.

aside --> The domain model's setup would make for a good data dictionary.  Each element that represents an attribute could define standards such as naming conventions, etc.