QuoteFor me personally that's too abstract, it will take me too much time to understand, but maybe others can help you in this phase. I really need real cases: instead of a house, student, etc. I'm also a bit worried that you'll have to adjust the design it you don't test it, .. So then we end up with the same design process, "prototyping".Fair enough. It takes some time to design s/w in this way. See the diagrams as the features in the system to build. I don't need prototyping (especially FDM) since most features are already known and my prototype (V1) works already. I am interested in the feasibility of boost (for example) to produce V2.Did you see my other FDM/MC diagrams? They are in the same style as the student example. When I finish my design I will produce corresponding POC code V1 and V2 which than can be tested.In the meantime what I really need is feedback on the domain issues because we are describing the problem and not the solution, yet.For example, the ins-and-outs of a UVM, mean-variance PDE, how to integate QMC and time series into a MC framework etc.All these diagrams are "C++ in diagrams". It's a skill that many programmers have not yet learned. Software design is in its infancy. BTW what I am talking about has been known for at least 40 years. OOP has ignored this technology, which is why OO systems are so difficult to maintain.
Last edited by Cuchulainn
on October 22nd, 2011, 10:00 pm, edited 1 time in total.