This week there has been a lot of design work going on in the group (we are gearing up for development on the next project) and I want to recap my personal experiences this week on modeling.
I worked mostly on designing the wsdl for our projects SOAP interface this week. I did what I call a tracer bullet design using Haskell. Basically I flesh out the data types and the interfaces in code but there is no actual implementation code. I just want to see if everything communicates intent well and is consistent as far as the compiler is concerned. Haskell is nice for this work. I can express a lot in a very small space so I can get a very good over visual overview of the final system I'm shooting for in one or two short files. Its like having a good map in front of me, I can take in all the important points in one view. Writing Haskell is also very close to writing in a specification language so there is the added advantage of being very precise while being very expressive at the same time. And lastly I didn't expect it before hand but I found that transforming my Haskell code into wsdl was very intuitive and straight forward.
Although it should be clear from the context, its only useful to do this tracer bullet development with a compiled language. Designing this way, one is using the language and the compiler together as a system design tool. And the better one can express ideas via the languages type system, the more design help the compiler will be able to provide.
One other idea in modeling that I have never heard expressed anywhere else...whenever one has a design one should alway compare to an existing design as a stress test. This idea is the same as the idea in statistics where one builds a model with data from a training set, but evaluates the model against separate set of data that is never consulted during the modeling process. A lot of models may have good predictive power against their training set, not so many look as good against the test / evaluation set, (and then the real world is another hurdle still.) With software, the idea is to review ones model against a design model put together by another engineer, or against a similar system designed somewhere else, or, if one is working on new generation of software x, check that one can still express the concepts of old generation software x in the new model. A good model encompasses the constructs of (-ie the accumulated knowledge of) other engineers and other attempts.
So to end this post, I will say to you what I felt today at work. 1. Uml pictures are long on pretty and short on constraints and trade offs. Long term very little of those pictures will survive the translation to real code in a real system. 2. People came before us and spent a lot of time thinking about the same business problems we are trying to model. We may be smarter and have better thoughts but how could we prove that?
Do your best -- Marco
I worked mostly on designing the wsdl for our projects SOAP interface this week. I did what I call a tracer bullet design using Haskell. Basically I flesh out the data types and the interfaces in code but there is no actual implementation code. I just want to see if everything communicates intent well and is consistent as far as the compiler is concerned. Haskell is nice for this work. I can express a lot in a very small space so I can get a very good over visual overview of the final system I'm shooting for in one or two short files. Its like having a good map in front of me, I can take in all the important points in one view. Writing Haskell is also very close to writing in a specification language so there is the added advantage of being very precise while being very expressive at the same time. And lastly I didn't expect it before hand but I found that transforming my Haskell code into wsdl was very intuitive and straight forward.
Although it should be clear from the context, its only useful to do this tracer bullet development with a compiled language. Designing this way, one is using the language and the compiler together as a system design tool. And the better one can express ideas via the languages type system, the more design help the compiler will be able to provide.
One other idea in modeling that I have never heard expressed anywhere else...whenever one has a design one should alway compare to an existing design as a stress test. This idea is the same as the idea in statistics where one builds a model with data from a training set, but evaluates the model against separate set of data that is never consulted during the modeling process. A lot of models may have good predictive power against their training set, not so many look as good against the test / evaluation set, (and then the real world is another hurdle still.) With software, the idea is to review ones model against a design model put together by another engineer, or against a similar system designed somewhere else, or, if one is working on new generation of software x, check that one can still express the concepts of old generation software x in the new model. A good model encompasses the constructs of (-ie the accumulated knowledge of) other engineers and other attempts.
So to end this post, I will say to you what I felt today at work. 1. Uml pictures are long on pretty and short on constraints and trade offs. Long term very little of those pictures will survive the translation to real code in a real system. 2. People came before us and spent a lot of time thinking about the same business problems we are trying to model. We may be smarter and have better thoughts but how could we prove that?
Do your best -- Marco
RSS Feed