So, I'm working on a project. Pretty big SQL setup, lots and lots of complexities. Good news is that the whole thing is described well with a "UML" document. There is also a tool in place to generate SQL-like stuff for MS SQLServer, but it takes advantage of some of MS SQL's quirks in the code it generates.
What I'd like to do is take the UML document as input, and have it spit out a bunch of ORM files for me in another language and just let the ORM's framework worry about the messy SQL details for whichever database ends up being used. Not only would this be (slightly) less tedious than manually building up the objects by hand, it would have the benefit of making the UML document a single point where the database could be managed in the abstract and I could get on with doing the stuff that's more computer sciencey and less data enterishy.
But. I can't. Because the UML file was created with a very feature rich UML editor that lets you draw really nice and really well annotated diagrams, but locks it all up inside of a very non-UMLish file format. And for the icing on the cake, the company that made the editor closed up shop in May and has decided to not only stop taking orders for their software but providing the free evaluation download as well.
From my point of view, this makes the file just as programmatically useful as a jpeg picture of a diagram of the database layout. The tedious grunt work of examining the diagram and manually hacking it all together is unavoidable, which means that now we've introduced the chance of documentation skewing away from the implementation. Inadvertent forks from last minute bugfixes or poorly communicated design changes are now on the table.
All because a software developer thought his method for storing UML data was better than just using simple UML, and that his clever method would assure him of job security.
Wrong on both counts, mang.
And now we're both hosed.
Just stick with the standards, people. Please?
No comments:
Post a Comment