As I mentioned recently, I've been thinking of how you could program UML-like actions using C++ in a manner similar to SystemC. As I worked through the workflows of how actions could receive data and signals on input pins and send stuff on output pins, and how they all hook up together, I started to get a deja-vu feeling.
It brought back a lot of good memories from my years at ObjecTime. You know, we had a lot of this stuff back in the 90's. Mind you, it was almost totally focused on state machines that communicated with eachother using messages, but it had a lot of the multi-threading, action oriented development that we need for multi-core systems.
It was a fun time back then. We were a company of 150 or so working on something we were all very passionate about. It was one hell of a team. And we had some big customers but not many of them. When Rational bought us we saw it as a good thing that would lead our work to greater exposure and a bigger sales force. It didn't pan out that way, but the team lived on and a lot of them are still working on modeling tools for Rational which is now a division of IBM.
But one area where I think we failed was in adoptability. We had some passionate early adopters as customers but there are only so many of those. You certainly don't want to build a business with only that. And it was hard to get the code centric guy to trust the modeling and code generation tools. Let's face it, when it comes to crunch time, you'd rather be in with the code with age old and trusted tools and the modeling tools easily fall by the wayside.
Anyway, that's why I work on the CDT now. Code rules, at least for now. But as we try to introduce complex programming paradigms to facilitate multi-threaded development, I got to wonder if there isn't another ObjecTime out there. We where years ahead of the industry and we knew it. I had feared that the time would never come, but maybe that's not true after all.
What's the difference between a model and code? Note that it's a trick question...
ReplyDeleteIs it better to rely on a person or a machine when it comes to doing the same tedious 10 things correctly 100 times? Note that it's not a trick question...
Sometimes, to be successful, you have to pander to people's paranoia. Doesn't the alliteration have a nice ring to it?
Exactly. The fun thing with the CDT is that we now have a pretty powerful model of the code with our DOM which includes AST and indexing. I'm hoping that people start taking advantage of it and building some cool visualizations. And with our new refactoring engine, doing edits at the model level and reflecting them in code is now easier. Sounds like a good presentation topic for ESE :)
ReplyDeleteDoug, there's indeed now a commercial tool that based on state machines plus a specific programming language, will generate you: VHDL, C++, SystemC code, ...
ReplyDeleteTake a look at : http://www.esterel-eda.com/products/
We need to regard things as a continuum, where modelling is an imprecise way of sketching, which gradually evolves precision and becomes a programming language onto itself. Code generation is I believe the biggest block to this process. When I was on WebSphere Integration Developer we had many simple models like state machines, decision tables, etc., which were wonderful programming metaphors complete with enough precision to be executable. But where they always fell down was in the code generation to some complex runtime, with ensuing complex debugging and back tracing. I always believed the right answer was that each metaphor (FSM, DT, etc.) deserved its own runtime interpreter, with first class traceability and debugging. Until we start treating models as programming languages then the programmers will never trust them.
ReplyDeleteDoug,
ReplyDeleteSome of the ObjecTime thinking is coming back in the work that we at Zeligsoft are doing just across the river from you.
Our solution is based on Eclipse through the IBM modeling platform.
The adoptability you mentioned is taken care of through domain specific modeling (using UML). Other key concepts are componentization, encapsulation and abstraction.
Lastly, we add visual modeling of logical platform (RTOS, middleware, processes, threads) as well as the physical platform.
Models allow you to express software independent from the hardware and to describe the allocations between them. These allocations are then input into the code generator.
Interesting stuff with many connections to the ObjecTime days.