Page 1 of 16

Architecture and Design

Posted: October 5th, 2011, 6:28 pm
by Cuchulainn
This is the thread for defining all things that have to do with software (minus coding stuff).

Architecture and Design

Posted: October 6th, 2011, 9:28 am
by Cuchulainn
Some slides shows on Layers and Microkernel patterns

Architecture and Design

Posted: October 7th, 2011, 8:04 am
by rmax
At a high-level we should look at it being a set of services that are being defined.

Architecture and Design

Posted: October 7th, 2011, 8:52 am
by Cuchulainn
QuoteOriginally posted by: rmaxAt a high-level we should look at it being a set of services that are being defined.Indeed!! In the sense of SOA and SOAP, for example?

Architecture and Design

Posted: October 7th, 2011, 9:26 am
by rmax
Exactly. This works well with the "renorm onion". I like the idea of having wrappers so you can engage with the service at which ever level you choose.i.e. Level 1: value an IRS using this market data points provided in excel and output the boot strapped zero coupon and forward curves + market sensitivtiesLevel 2: Value this IRS but use market data from this service (internal or external)Level 3: value the IRS but I will provide the bootstrapping for the curvesFor educational purposes it would be nice to an analogy of a cutwaway diagram of the engine. I.e. you could see the various underlying numbers that are being calculated etc. The services can then be called from Excel, GRID engine, matlab, web etc.

Architecture and Design

Posted: October 9th, 2011, 11:29 am
by Cuchulainn
Master Planner: Fred Brooks Shows How to Design Anything QuoteWired: How has your thinking about design changed over the past decades? Brooks: When I first wrote The Mythical Man-Month in 1975, I counseled programmers to ?throw the first version away,? then build a second one. By the 20th-anniversary edition, I realized that constant incremental iteration is a far sounder approach. You build a quick prototype and get it in front of users to see what they do with it. You will always be surprised. How many libraries get thrown away and start again?? How many are incrementally improved?

Architecture and Design

Posted: October 9th, 2011, 1:24 pm
by hamster
QuoteOriginally posted by: CuchulainnMaster Planner: Fred Brooks Shows How to Design Anything QuoteWired: How has your thinking about design changed over the past decades? Brooks: When I first wrote The Mythical Man-Month in 1975, I counseled programmers to ?throw the first version away,? then build a second one. By the 20th-anniversary edition, I realized that constant incremental iteration is a far sounder approach. You build a quick prototype and get it in front of users to see what they do with it. You will always be surprised. How many libraries get thrown away and start again?? How many are incrementally improved?Improvementi think the main obstacle for incremental improvement is no or not enough code commentary. a new guy who get the task to improve stuff have to understand the existing code. there is a saying you should comment more than less. hmmm... i get used to to write summary comment why the current code sucks (at least i try). ... or that i heard that there is a better solutions ... or why it become a problem for reusability (eg. software you have already in mind)... that is quite helpful some months later.at least there is always a guy who know better, is smarter, more experienced in programming.dont waste his time to understand the messiness and slatternliness of your code. be honest and tell him how the code sucks. librariesActually boost is an good example. it uses ATLAS. but ATLAS includes not all LAPACK routines. then it might happen you need the missing LAPACK routines. So guess what happens? Noooooo... you dont call missing LAPACK routines in your C++ (or integrate a nice way), you will write old-new algorithms in C++ (at the risk that the LAPACK algorithm is state-of-the-art, and your's is not).

Architecture and Design

Posted: October 9th, 2011, 3:02 pm
by Cuchulainn
QuoteOriginally posted by: outrunI've a atlas with full LAPACK integrated! LAPACK does BLAS calls, and can work with any blas implementation that follows the blas interface. We should also focus on stable interfaces so that we can keep it modular.Is this necessary and sufficient? (1-stop shop).

Architecture and Design

Posted: October 10th, 2011, 7:46 am
by Cuchulainn
Here is an UML class diagram (> 7 years ago at this stage), but it does show interfaces, decomposition and loose coupling.

Architecture and Design

Posted: October 10th, 2011, 8:17 am
by Cuchulainn
QuoteOriginally posted by: outrunThanks! That looks like a very good discussion slide. Very good.One very quick idea: the "explicit" "implicit" choice, that can also be done with type tag dispatching instead of inheritance? Or am I reading this wrong: it's an orthogonal discussion, right?I hope to get the 3 new chapters on this soon. An I think this model can be applied to MC as well. (both are instance systems of a RAT domain architecture).Instead of inheritance I could use other techniques: it's a *tradeoff* between run-time and compile-time behvaiour. Some dynamic polymorphism is awful useful.