When we design applications, we generally end up with the same tiered sets of data structures:

1. A persistent data structure that is described using DDL and implemented as RDBMS tables and columns.
2. A set of domain objects that consist primarily of data structures, usually combined with business-rule level logic, that are implemented in a programming language such as Java.
3. A set of service layer interfaces that directly support use case implementations (which use the domain data structures as parameters), implemented as EJBs or something equivalent in another programming language.
4. UI screens that allow users to C reate, R etrieve, U pdate, and (maybe) D elete all manner of data structures and graphs of data structures, with numerous screens and with multiple UI widgets, all structured to support the same data structures.

But if you want to change the data structures in any of these tiers, it always seems extremely difficult to assess the impact(s) the change will have across the application. UML can help, but tracing through diagram after diagram is not a real solution to this problem. The best I have ever seen was a homespun data tracking spreadsheet document that listed all of the data structures and walked the relationships from tier-to-tier.

Is there a tool or accepted approach that makes it easy to identify a data structure in any tier and easily obtain a list of all dependent:

• database table and column data structures
• domain object data structures
• service layer interface methods and parameter data structures
• screen & UI component data structures