Audit trail front end design

I need a centralise work on audit trail front end. I don't want each module to have their own audit trail layout format. Thus I make a generic bean that could store the result and publish it into a generic table that shows pre-data on the left and post-data on the right. Yes, this bean is playing the main role connecting the back-end and front-end.

Besides that, I need flexibility, and I don't want to change my core everytime you have new field introduce in the table. Thus I made another bean to represent that fields in each the table. Instead of table, I would rather say view because each audit trail module will have different representation of a module. e.g. claim module, payroll module, and etc.

Lets reveal the design.

I made an abstract audit header object, and an abstract audit content object. The purpose of making them abstract is to increase its flexibility design when interacting with controller class. Thus the controller class do not care about the type of audit, "I don't even want to know! Please leave me alone." Controller class says.

Each header must come with a content. At least one content. Thus I made a composition associate between audit header and audit content. How? By using the black diamond. I use composition (black diamond) instead of aggregation (white diamond) is because of my way of design. I want each audit must come together with at least a content, otherwise don't render this page.

I use generalization to realize the type of audit. As shown in the picture, the audit header and audit content is realize the claim audit.

If the content are ready to be distribute, the controller class will collect it and put it into a public access Bean object.

As shown in the diagram above, the controller class is the middle man who trigger the request and distribute to JSP page. In JSP page, user still have to tell what type of audit content should the controller class to retrieve.