"Modern" Software Framework?
in [OOP]
|
Prev: Design by Contract vs Law of Demeter : Preconditions
Next: New England Patriot jerseys for men,worldwide express, paypal payment
From: Dmitry A. Kazakov on 18 Aug 2007 03:46 On Fri, 17 Aug 2007 15:30:32 -0700, philip_b_taylor(a)yahoo.co.uk wrote: > Sorry perhaps I was not clear enough. There is, of course, no > intention of using Python on the real-time platforms - the requirement is that > Python be inter-operable within the framework used, not that it will be used on > every host in the system. Python (and to some extent Java) will be mainly used in > the supervisory and scripting tiers of the system. Some (soft) real- > time hosts will use C++, perhaps Java. There will be specialist hard real-time > processors which may have to be excluded from the framework. But in which sense interoperable? Consider Python software being a publisher. The things it publishes should have certain QoS (say, jitter <5ms), so? The point is, it is very difficult to insulate an RT part from the rest of the system. Even HMI has RT requirements. For instance, you hit the "emergency stop" button and in 20ms it has to reach all actuators. IMO, a quite common misunderstanding is that an RT transport layer would automatically make the system RT. It does not. The software does. > As regards size, I don't know, except 'large'. There should be no size > limitations imposed by the framework. This is in a sort of contradiction with RT requirements. Can the system be modified on-the-fly (process variables/connections added/removed, QoS parameters changed)? Can the system be able to estimate QoS before run? Should the system control and optimize QoS? > My guess is ~100 hosts and 100K+ I/O points? Yes, this is close to the upper end of the systems we dealt with, ~30 nodes, ~300K variables. > There's a couple of years detailed design yet to go. I am very intrigued. If possible of course, could you tell more about the project? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: philip_b_taylor on 18 Aug 2007 06:06 Thanks for the suggestions so far - the only really new one is Ruby on Rails, which I I had not considered for this type of system. I know very little about it, but the Ruby on Rails website states "Rails is all about infrastructure so it's a great fit for practically any type of web application Be it software for collaboration, community, e-commerce, content management, statistics, management." So it never struck me as as relevant. I may be wrong. Someone was surprised that we want to use Java, C++ and Python. Simple reason: re-use of legacy code and available skills. We may be introducing new languages but don't want to add many more, ideally reduce. Good point about C++ being older technology than CORBA, another reason for phasing it out...the performance hit of Java (the main reason C++ was used) is surely becoming a thing of the past. As regards RT constraints on a Python-based system like 5/20 ms jitter. We would never require that kind of performance throughout the whole networked system. Millisecond range stability will be confined within single nodes or perhaps closely-coupled subsystems. Safety-critical systems will be separate, direct hardware/PLC interlocks for close- down etc. As software engineers we leave that stuff to the hardware guys :) As regards the 2 years design - I mean that the hardware is being designed during the next 2 years rather than detailed software design (which yes would be unwise and anyway premature). Philip
From: Dmitry A. Kazakov on 18 Aug 2007 06:55 On Fri, 17 Aug 2007 19:39:04 -0700, Phlip wrote: > philip_b_taylor wrote: > >> There's a couple of years detailed design yet to go. > > Please google for "waterfall". Such a long _detailed_ design phase is > setting you up for _assured_ disaster. No, you can't sell TDD here. Let me try to explain why. There are two general archetypical approaches to design: top-down and bottom-up. What you refer as "waterfall" falls under top-down. Your TDD is bottom-up. In OO terms moving top-down is equivalent to specialization. You start with the most general system functionalities and them put [implementation] constraints on them. TDD is equivalent to generalization, you start with a minimal working set and then add new / extend old functionalities and features. This is why you cannot do TDD for a system having many non-functional requirements (like QoS). This is fundamentally incompatible with the evolutionary approach of TDD. For all, non-functional requirements are non-testable in the sense that a successful test does not tell you anything useful. It might work with 255 variables and collapse with 256. The induction: it worked for n => it will work for n+1 is obviously wrong. The reverse works, you can add constraints keeping the system working. This is why up-front design is the only way to go for such system. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Phlip on 18 Aug 2007 10:11 Dmitry A. Kazakov wrote: > No, you can't sell TDD here. > > Let me try to explain why. I stopped reading here. -- Phlip http://www.oreilly.com/catalog/9780596510657/ "Test Driven Ajax (on Rails)" assert_xpath, assert_javascript, & assert_ajax
From: Phlip on 18 Aug 2007 10:11
philip_b_taylor wrote: > another reason for phasing it out...the performance hit of Java (the > main reason C++ was used) is > surely becoming a thing of the past. I'm getting a lot of "management by magazine" here. C++ is more programmer-friendly than Java, and of course faster. All the hype about Java being "programmer friendly" is just that - hype. Java's speed is irrelevant if you just install more memory to avoid thrashing. The point of Java was supposed to be "C++ without stray pointers and index overruns. Instead, we got a language that makes you jump thru hoops and write excessive cruft just to get anything done. Java - the elegant simplicity of C++, the blazing speed of Smalltalk. You need to settle on two languages. The one closest to the metal should be compiled, deterministic, statically type, and as programmer-friendly as possible. The one closest to the users (the soft layer) should be interpretive, emergent, dynamically typed, and much more programmer-friendly. Adding Java (interpretive, deterministic, statically typed, and programmer-hostile) will just slow you down. > As regards the 2 years design - I mean that the hardware is being > designed during the next 2 years > rather than detailed software design (which yes would be unwise and > anyway premature). Ooookay. Why wait 2 years to start _building_ the software? Why not let software development assist the hardware development? There's nothing "premature" about starting as early as possible, to give you the longest runway. -- Phlip http://www.oreilly.com/catalog/9780596510657/ "Test Driven Ajax (on Rails)" assert_xpath, assert_javascript, & assert_ajax |