Dependency links to attributes?

[CJ]

G'day g'day,

I have a report component that accesses many tables, several columns from each table.

Although I can easily show the component's dependencies on the tables, I'd like to show the specific columns the component depends on.

Is there a tidy way of showing dependencies to attributes?

Setting the source roles on the dependencies to the tables' attributes works, but I'm not quite sure that's the best way to go.

[sargasso]

Hmm, yes I see what you mean.    Even if you use roles you will end up with very busy diagrams.

However!  What exactly are you trying to describe.  Ino other words - what is the model being used for when its built.  The relationship between a component and a table attribute intrigues me.  Why does a component have a dependency on a table attribute (column)?

B

[CJ]

Top o' the mornin' to ya (I want to follow that up with "Have you had yer Lucky Charms?"),

The ability to setup dependencies on attributes would allow us to identify  the impact of change to an attribute: we could easily identify all components (screens, reports, etc.) affected by a change.

It's easy to document these relationships as independent or embedded notes, but notes would be a pain to maintain.

Maybe there is a way for me to get what I'm looking for, but I'm not seeing it.

[mbc]

CJ

Now, I don't do much work with databases and tables, but I will try to imagine your scenario with a class CMyClass instead of your table, and I hope the conclusions are still relevant to you.

Imagine that I was in a situation where other elements (components, classes, ...) in my model depended on only parts of CMyClass while other parts of it were irrelevant. That is, irrelevant to such an extent that I would want associations to individual operations or attributes rather than the whole class, then alarm bells would start ringing. It is a warning that the design needs to be re-thougt. The two solutions that come to mind are:

1. Split the class into smaller classes where the members are so highly cohesive that they will rarely be used without the others.

2. Create an extra layer of abstraction, e.g. some interfaces, through which the other elements can access only the members that they need.

I hope this might apply somehow to your table.

Mikkel

[CJ]

G'day Mikkel,

I don't think that you can draw that kind of parallel between database model and software class model.

For example, say I have a table "Building" with the following attributes:
- bldg_name
- bldg_location
- construction_year.

Now let's say I have 5 reports/screens that only show bldg_name, 4 that show bldg_name and bldg_location, and 2 that show all attributes.

I really would not want to create three distinct tables to store each of those attributes separately.  That would make our applications and database administration so much more complicated.

[thomaskilian]

CJ,
there is probably no good way to show these associations. I'd vote for views(/interfaces) for such cases where you need to constraint the use of the table to certain column names.

[mbc]

CJ,

I agree with you that your example contradicts my solution 1, but I think my solution 2 is still applicable.

Mikkel

[CJ]

G'day g'day,

I'm sorry Mikkel, I dove right in on your first suggestion without giving the second one even a quick glance.  I'll have to go over some books to see if any of them give examples.

Much appreciated.

[CJ]

G'day folks,

Here's what I've finally decided to do.

I'm setting up my domain model so that things that would normally be attributes (like "building name") are instead classes of their own.

So, anything in our system that references that attribute (say some field on a form, or some field in a report) has a dependency on the class that represents that attribute.

Now, if building name changes in any way (for example, the size of it), I can easily evaluate the impact of that change on the system by reviewing all dependencies, and find out all classes and components that will need to be resized.

Thanks again for the help.

[mikewhit]

Does rather highlight a need in EA however - either (1) allowing attributes to have dependency relationships in order to track their individual use, or (2) improving the reporting functions to show attributes in, for example, a matrix view.

[CJ]

G'day,

Does rather highlight a need in EA however - either (1) allowing attributes to have dependency relationships in order to track their individual use, or (2) improving the reporting functions to show attributes in, for example, a matrix view.

I'm more of the opinion that the UML should define a standard for the feature (externalizing attributes?) and that EA could then provide something on such a basis.