6

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
Improve this question
3
  • OO claims that it features encapsulation!Somebody must have lied. On a more serious note, your debugger should help.
    – NoChance
    May 8, 2012 at 10:09
  • 4
    @Emmad. Encapsulation protects against changes to the implementation behind the interface, not a change to the interface itself.
    – mike30
    May 8, 2012 at 18:05
  • @mike, thanks for your comment. You are correct. One defintion of encapsulation is: "A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data" using this definition, even though you may have layers, all infromation about the customer could be though of to exist in one place. The customer class. But this is not possible in today's environments. That was my point. The definition is taken from: en.wikipedia.org/wiki/…
    – NoChance
    May 8, 2012 at 20:24

4 Answers 4

Reset to default
4
+50

In Java you can get at least some help from Hibernate and JPA. With that combination you can describe the complete data structure in Java objects with annotations and Hibernate will generate the DDL and, if configured to do so, update the database schema when you change the objects.

On the front end, you could deliver the data in JSON format so that you could implement a data-driven UI in JavaScript and dynamically build your CRUD operations using labels and values present in the JSON representation. There are libraries that convert Java objects to JSON using introspection, so there would be little to no additional support needed in the data objects.

Typically the front end CRUD operations need a lot of fine tuning to make them palatable for users, and maybe even help text, for example, and there's no getting around that.

It's probably even easier using Ruby on Rails, but I haven't looked into it yet.

Improve this answer
1
  • Agreed. The usage of Hibernate that you describe does help tame this beast during development. One team I was on functioned completely without a DBA, because we let Hibernate control the database structure. We were all worried to start, but it worked very well and it made it fairly easy to make large changes to the database structure. But that said, we still had to scramble after Hibernate made the changes, because there was no easy way to determine what impact changes to a table would have across the app. Strong and automated unit testing was our only defense in the end. Great feedback!
    – Sean Mickey
    May 11, 2012 at 23:24
2

I don't know of a general tool for such a task, but I suspect that there are specialized ones that can get you partway there, especially if you stay within a popular introspective language like Java.

I must say this is an extremely thorny problem, especially because each layer is typically written in a different language, and the tendency is to code the data structure natively in each layer, perhaps with the aid of a code generation tool. Any tool that could cut through that would have to be able to parse several languages and tease out the related data structures. To make that tractable, I would imagine that either special markers would need to be embedded in the code for the tool to find, or else each layer would be generated dynamically from a master data definition language (not necessarily a traditional DDL).

Improve this answer
2
  • Yes, it is always a thorny problem and it just strikes me as strange that we, as an industry, continue to handle things this way. It seems that such a fundamental aspect of systems would have been addressed more fully. I'm not whining; I just find it strangely fascinating that we all work this way.
    – Sean Mickey
    May 8, 2012 at 20:14
  • I think it reflects the way we, as people, tend to operate, @Sean Mickey. An originator of a task/design/idea/plan tells a delegate, who tells others, and so on, each expressing it in their own words. Rarely is a fixed message transmitted verbatim across a chain of command. The structure of a system reflects the structure of the organization which created it, as they say. In other words, programs reflect people. Perhaps if we took a data-centric approach to information processing instead of a code-centric approach things would be better.
    – Randall Cook
    May 8, 2012 at 20:26
2

There is no magic except probably documentation as you are already doing. The thing is to keep it updated once this doc exists and make this mandatory during code review or QA. There are Enterprise Architecture tools like Mega etc. where if you set thing properly you can trace from DB to even business process. But these tools are expensive, heavy and requires dedicated architecture team to manage which may be overkill for smaller organisations.

Improve this answer
1
  • It is true that Mega tries to address and track aspects such as this, but just as you say, it requires a dedicated, disciplined, and ongoing effort. Most teams struggle just to keep the documentation up-to-date, much less a heavyweight toolset.
    – Sean Mickey
    May 8, 2012 at 20:23
0

I'd focus on the application server log as it frequently has entries for view calls, controller actions and database calls.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.