Prepared
Nov 2007
Many non-trivial construction projects require a broad range of resources from more than one vendor. The trend has been to break the project into different scopes for various sub-contractors to bid on and implement. From a business perspective, this is an excellent way to proceed, as it takes advantage of the bids and tenders mechanism to help keep the budget under tight control.
From a data management perspective, it is a pretty serious challenge. Construction projects require that very detailed information is shared between all of the sub-contractors. The software tools and mechanisms selected to achieve this will have a marked effect on the cost of running the data side of the project.
This document puts forward some of the ideas used in one such construction project.
In big projects, management tend to follow a divide and conquer approach, assigning different pieces of the puzzle to separate development teams. What happens a lot, is that these teams go off with their business specs and build something which more or less fulfils the spec, with very little concern for what the other team is doing. Usually there is an integration requirement somewhere down the line, one of the new systems must exchange data with the other. If not directly, then via a third system.
The author has long suspected that just about everything in business is related, and if applications are to be developed that also play in different areas of the business then, so too should those applications be related.
It was decided to make the data model a real working re-usable component in all of the applications developed on the project. This would allow the relationships discovered in the course of analysis to be represented in data, and then exploited by any of the interested applications.
The best way to achieve this, was found to be the use of an Object Model with OR mapper technology. Hibernate was chosen, as it was well proven, and low cost.
The screen shot below is of the UML static class diagram of the common data model used.
The classes are grouped together with a solid background to indicate areas of interest. Each one typically supporting a dedicated application.
The systems required here go way beyond simple CRUD operations, and as such a minimum of 3 layers are required to separate the business logic from the data layer, and the UI from the business layer.
The diagram below shows that architecture was used. The business layer (in blue) makes use of data transfer objects to exchange with the User Interface (Presentation Layer). The DTOs allow us to hide unnecessary complexities in the Data Layer, from the UI.
Both the Session and Data layers make use of a utility API (in Pink) that wraps the functionality of Hibernate to provide a generic OR mapping facility. The wrapper allows the Session layer to have some independence from the Hibernate API, as it was always a possibility that a different OR mapper be used in the future.
The following screen shots are of a couple of the applicatons that share the common data layer.There are eight in total!
The web client provides reference data management for all the other systems, as well as user role security and general browsing of received data.
Menu
The windows client is used to provide a standalone user interface to the engineering tag data in the database. Features for import and validation are included.
Imports are multi-threaded and managed via the Jobs tab shown in the second screen shot.
Browsing Classes
Importing local file
