A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
To those who are interested in visual programming, I've released a new website http://www.cogiton.com that proposes a new take on UML and fixes several key problems with their notation. The technology is called "Cogiton Software Circuits", and is laser-focused on making pictures == code in object-oriented classes.
The site has both an online book which lays out both the need for the approach as well as how to implement it. And its all free.
First off, Software Circuits *only* tackles the organization for object-oriented classes. It doesn't handle use cases, sequence diagrams, class relationships etc. Instead, it focuses on what is truly broken in UML - the organization of classes. Software Circuits give a straightforward approach to creating the internals of classes with an organizational pattern developers can implement w/o needing a tool. Additionally, the pattern is portable to all modern object-oriented languages. So if you've drawn the software, you've coded it. With UML, there is still a lot to fill in once the pictures are done.
Software Circuits are a form of improved state machine. State-Oriented Software is just plain better than the usual hacking, and I outline why in detail in the first chapter of the book.
Although you don't need a tool, it always helps, right? I also intend to soon release a browser-based one which will allow users to create a software picture, save it as XML and then generate code in most OO languages. Once again, for free.
Please take a look at the site and let me know what you think about the approach or if you have any comments or questions. I'll do my best to get back to you.
Some impressive stuff, but IMHO breaks on the assumption that UML (or any diagramming techniques) is a better way to write programs. The power of pictures is in conveying high level ideas, not details. Text (i.e., a programming lanhuage) is better at the details. See http://www.martinfowler.com/bliki/UmlMode.html
Wednesday, March 14, 2007
How does this differ from the Eclipse Modeling Framework? While I only have a vague understanding of EMF, your description and site sound somewhat similar in direction. EMF's modeling framework, ECore, can be built based off of an XML Schema or through UI modeling. It can generate the Java classes off of the model for customization, etc.
Wednesday, March 14, 2007
Thanks for the responses, and these are important questions. It will be a challenge for me to differentiate Software Circuits from other visual modeling approaches -
there are lots of them. Let me start with the issue of text vs pictures.
I fully believe Martin has a point with UML as it now stands. However, Software Circuits introduces some key innovations that may change that calculus for you.
In doing so, I made two innovations on the state of the art. The first was the behavioral inheritance mechanism. Statecharts in their full glory, done correctly, are nearly impossible to implement by hand (I can explain why, but it is a bit involved). With Software Circuits, however, you can get 95% of the needed factoring power in an almost trivial fashion. Check out chapter 4. The mechanism is called the "Event Map".
Going beyond, I have additional inheritance mechanisms which I believe provide even more power than UML does, and I will be releasing that material as soon as I get it ready.
The second innovation was the interface between the Software Circuit (declarative generated code from a picture) and user created code - what I define to be an Action. UML allows for big chewy text descriptions of the predicates in guard conditions. In contrast, Software Circuits require Actions (user code) to summarize their behavior into -ta da- an integer. In doing so, it provides an incredibly simple mechanism for interfacing between the two types of code. I call this integer protocol an "Action Result". Take a look at the demo and the Div0 state. You will see an example of an Action Result modifying an Event to take a different paths.
As to EMF, there are a couple of points.
First of all, its very Java focused. Software Circuits are language independent and we will soon be providing XSLTs to transform them into most OO languages.
Secondly, it is pretty complicated and the scope is large. Software Circuits, howerver, are completely focused on building objects. Not on their relationships to other
objects, class inheritance, data stores etc. We may get there, but I want to build out on a firm foundation of State-Oriented Software first.
To bring the response back around, the big question I frame in the book is not pictures vs text. Instead it is Event-Oriented Software (EOS) vs. State-Oriented
Software (SOS). In the introduction and Chapter 1 I lay out my case against EOS (what you probably do now). It has several key flaws as a way to create "brain"
logic for objects. I analyze why it doesn't scale well and why it violates the most basic principle of computer science - don't repeat yourself if at all possible.
Hope this lends some clarity. Let me know if you have any other questions.
> I have experimented for 8 years with creating state machines/UML statecharts by hand in the code.
Ever since I read http://www.amazon.com/Real-Time-Object-Oriented-Modeling-Bran-Selic/dp/0471599174 I've been wanting to have CASE tool support for writing state machines.
> Statecharts in their full glory, done correctly, are nearly impossible to implement by hand (I can explain why, but it is a bit involved).
Apart from coding state machines by hand, have you surveyed available CASE tools?
Is this specifically for coding state machines?
> Let me know if you have any other questions.
What's your ambition? Are you writing a book, developing a CASE tool, sharing an academic interest in diagram notation? Do you have a software development schedule?
Thanks for your interest.
I too had a rather dramatic conversion experience to State-Oriented programming when I was a developer at Microsoft.
I was so impressed with the clarity it brought to the problem I was working on that I have been experimenting with and thinking about software development from that perspective ever since.
I also worked for a few years on the Visio development team, which has a prominent UML design module. Surprisingly, nobody used it at the company to design our own software.
I have looked at many of the tools for CASE development, but many are very specialized such as LabView or are trying to implement UML in a better way. Unfortunately, UML is critically flawed in terms of creating objects based on state machines.
IN answer to your question about if this technology is specific to coding state machines, the precise answer is that is about how to code objects, using any OO language, as a new form of Hierarchical State Machine (HSM). HSMs enjoy all of the benefits of state machines, but also provide factoring techniques for common behavior between states.
As to my ambition, I am doing all of those things you mention. The online book is needed to both lay out the case for the need for such an approach as well as to clearly state just what the solution is.
The next step is to finish the web-based tool that is already under way. I hope to release it to the public before summer, and it will be freely available. My first implementation was in AJAX, but I'm seriously investigating Flex now.
In the meantime, I intend to get some templates in a bunch of languages up on the site to demonstrate fully functioning classes using Software Circuits. That should be a matter of weeks.
> State-Oriented programming
I'e been interested in old-school finite state machines:
* X internal states
* Y external events
* X*Y event/state combination ('methods')
* Each method may include an action (e.g send a message) and a state transition
In order to reduce the number X*Y there may be shortcuts (perhaps implemented like, I don't know, http://en.wikipedia.org/wiki/Aspect_%28computer_science%29 or something), for example:
* There may be super- and sub-states
* There may be methods associated with state exit (teardown) and state entry (setup)
* A state transition may be guarded ("even if a method tells you to, don't leave this state if this other condition is true")
Then there's deciding whether to model state as a formal State or as an instance variable: for example, would you rather have 30 states plus a boolean (which applies to any state), or would you rather have 60 states?
There may also be subclasses of event. Some of the events may be generated internally (send a message to yourself). Messages have a sequence, which may not be known (e.g. if I send a message to A and B, and they reply, you don't know the sequence in which the replies will arrive)
That ROOM book that I mentioned above was about an actual software product: initially "ObjecTime" (a spin-off from Bell Northern Research), later acquired by Rational (as "Rational Rose RealTime"), then acquired by IBM...
... the book talks about some of the ideas you're demonstrating, e.g. a diagram that's executable, interactive, testable, debug-able
... not to mention navigable (e.g. 'drilling down' into sub-states, given that it's all too complicated to have as a single diagram).
... and then there's forward-engineering the thing to whatever platform you want to run it on (e.g. C++).
I guess I'm going to respectfully dissent here. Apart from being a verbal rather than visual person, I do have experience with graphical ETL tools like Informatica. What I found was that whenever you put real-life business logic into the pictures, the diagrams quickly became as complicated to read as a circuit diagram. Having spent the first part of my career writing diagnostics for hardware engineers, I can say that it's not easy to debug complicated pictures.
With Informatica, I found that whenever the logic got really complicated, everybody drops down to stored procedures. Then, you just get really expensively created documentation.
Christopher, with regards to ROOM. Can't say for sure, but for all the issues you mentioned, I have some kind of mechanism in Software Circuits. I have two more chapters in the book to be released ASAP which deal with advanced HSM implementations using nested Software Circuits (read state machines), but the material I have on site already is probably sufficient for 80% of most common stateful objects.
Steve, I completely agree that trying to design complete architectures with pictures gets ludicrous. So 2 points as an answer:
First, I have proposed generic *code mechanisms* for each and every part of the picture. You can choose never to use the pictures at all, and, I believe, still build better software using the approach.
Secondly, the scope of Software Circuits is *totally* on how to build *individual* objects. It really is the level that most of us focus on all day long and where most ambiguity arises - not in object relationships where UML is strong.
Also, if you have more that 10-15 states in a single object, some refactoring might be in order. Even so, if you take a look at my demo http://www.cogiton.com/demo/Calculator1/calculator_modified.xml
you will see 13 states that all fit on a single sheet of 8 1/2 x 11 paper.
The primary discovery I've made for myself is that programing using state machines (+improvements) is an inherently superior way to code - using pictures or not. The code is physically structured better - but you have to invest a bit of effort to build the supporting infrastructure.
I really want people to be able to do these techniques WITHOUT a tool. The tool will make it easier, but should *not* be required. I've designed Software Circuits to accomodate as at this point I have no tool for you :) Ya gotta do it by hand for now.
So I think you can have it either way: code === pictures (if some PM wants to document what you've done after the fact) or pictures === code. Your call.
All sounds a bit http://worsethanfailure.com/Articles/The_Customer-Friendly_System.aspx to be honest.
btw, what does 'laser-focused' mean?
Laser focused: I don't try to solve any other problem than how to build a single object. That's it.
I understand there are problems with the existing paradigm - that's my opportunity :) I think I've solved some of that mess you showed. Not quite sure if that was for a single object or a whole workflow. If the latter, that is not at all what I'm proposing.
If you're not interested in pictures, at least consider the State-Oriented Software story - you can do this by hand and never, ever draw a picture and improve your software tremendously in terms of intelligibility.
I'm actually quite intrigued by how much push back I'm getting on the pictures - I think it is great. I personally have loved coding these things by hand for years but thought I'd never get traction with that angle.
The first view I started out with was actually a tree view which I abandoned thinking nobody would be interested. I'll have to give that some more thought as the tool gets put together.
If you take a look at the demo mentioned above, you'll see some visual normalization techniques such as only permitting a single wire between two entities on the picture. That helps cut down on a lot of the clutter. The "circles" also allow you to route the wires "to the back of the board". This saves a lot of clutter as well.
Very nice visualization! You could sell this as a tool in its own right.
Your statement that hand coding statecharts is difficult seems contradicted by the Quantum Framework developed in _Practical Statecharts in C/C++_ by Miro Samek and boost::statechart. See http://www.quantum-leaps.com/ and http://www.boost-consulting.com/boost/libs/statechart/doc/index.html
It would be interesting to see your diagrams and visualizations auto-generated from statechart frameworks and traces rather than vice versa.
Thursday, March 15, 2007
Well, I certainly didn't mean impossible. Miro Sameks's book is on my shelf and provided the starting point for the demo, actually. His implementation was a continuation of Ian Horrock's analysis of the Visual Basic 4 sample calculator in "Constructing the User Interface with Statecharts".
Thank you for the compliment btw.
However, Miro seems to be very focused, as are many of these tools such as LabView, on embedded systems. I'm a desktop/web application developer and these approaches didn't really do me much good.
And I also didn't want to have to have a framework - I wanted to be able to create HSMs in any OO language in a consistent fashion and completely bound all impact of the approach at the object level. No external dependencies.
And as far as I know, Miro's approaches are all C++, but I'm not completely sure about that.
Your calculator demo was definantly impressive. I just want to say thank you for sharing all of this. It has moved to the top of my list to learn, and possibly implement at my work!
Thursday, March 15, 2007
Thank you very much for the complement.
There are two more chapters of the book that my editor is reviewing now. As soon as they are up, the system will be fully described. I'm afraid I've left you hanging at the moment on how to actually get an Event into a Software Circuit!
If you have any questions or comments, you can reach me at the contact info on the website. Any feedback - good or bad - is definitely appreciated.
Keep up the good work! I recognise many of the problems that you address.
What I missed (or did I look in the wrong direction) is the ability to view the .pdf or HTML for the entire book. Makes it much simpler to read.
Friday, March 16, 2007
No, I haven't published it as one document as I am, quite frankly, using it as a motivation for people who are interested to come to the site and see what is new.
This is also my way to get people to comment on it and give me feedback.
I hope this is not too much of a burden, but I would like this to be the way I make a living soon and need *some* enticement to keep people coming back to my site :)
I am exploring the idea of self-publishing it in print form if I don't get any traction with a publishing house. Your comments may help my case with the publishers!
Demo doesn't seem to work. Web page layout seems messed up. Pages don't say what they are for. There is no site navigation. Couldn't find a concise explanation of anything there, or diagrams of this new system. Top page just looks like a standard flowchart.
It could be something cool, but how would I know?
Focus your efforts on the site. And hire a technical writer - your own prose is too dense and academic.
Friday, March 16, 2007
I defiantly prefer a printable form. I have limited internet access at home, so I like to print reading material from work. Separate, it just makes the barrier to reading it all higher.
Friday, March 16, 2007
Hi Meghraj - can you tell me what browser/os and versions you are using? I am a one man shop running with my hair on fire so resources are, shall we say, limited. I have not tested it outside of Windows XP, Mac and Suse Linux w/ IE 6, 7 and FF 2.0+.
As to the printable form, I will work on getting a book for sale as soon as I can. I'm sorry I don't have anything at this time for you.
+1 for the print format.
This looks very interesting and I would be looking forward to read it either as a book or as a magazine article (MSDN mag, maybe?). It would also improve the status quo of your work.
Sunday, March 18, 2007
I'm definitely trying to get that moving. The next version of the site will have chapters 5 & 6 (next week or so). After that, getting published in print somehow is a top tier priority.
Its a bit of chicken and egg problem, but your comments (and other's as well) will hopefully convince some editor to dig into this a bit more.
Sunday, March 18, 2007
Although I have not yet looked through your book the first thing that comes to my mind is that until object interaction can be modeled through this technique there will be a gap.
Perhaps I just need to take a look at the demo (going to try running the calculator demo on my PC as it is not working on Safari). I am hoping that the demo and the book will reduce this concern. Regardless you do pose some intesting points.
another average joe
Sunday, March 18, 2007
Thanks for your input.
I have found that expressing object relationships is where UML is strong, or strongest in any case. I especially find sequence diagrams to identify classes, relationships and protocols to be the most useful way to start. Its also very Agile, as you just start tracing out a success path on the whiteboard, with your team, for an operation, and these things (classes, APIs, etc) just fall out of the analysis. That is really useful and usually pretty fast.
But once you have those classes identified, unless they are trivial (my definition of trivial being an object that always responds exactly the same way to a set of events - in essence the class only has one state) UML is very problematic about how to actually build stateful objects. Thus the initial focus of Cogiton Software Circuits on object-oriented class architecture.
Look forward to any ideas you might have about weaknesses in UML in these areas. I do believe there is more to do once some groundwork has been laid in fixing class architecture.
Sunday, March 18, 2007
This works for a calculator, but is it going to work for any decent size application?
Sunday, March 18, 2007
Cool stuff Mark...I look forward to investigating this in the future
Monday, March 19, 2007
Thanks for the comment Jack. Please keep checking back - the next chapters should be done in a couple of weeks. The tools and templates are next after that. I'll be looking forward to input on what implementation people like with their favorite languages.
Outback - the critical point is that this approach is completely about reworking the *interior* of object-oriented classes, and has *no* impact on larger architectural issues. The overall footprint of your objects and their external relationships are completely maintained.
Most objects will be *much* simpler than the calculator, but for those that aren't the state-oriented approach has been, for me, the only way to make the problem as simple as possible. The reason for this is because states clearly identify the small subset of overall functionality (events mapping to behavior) that is active at any one time. You don't have to hunt through *every single event handler* to figure out the impact of a change.
Monday, March 19, 2007
This seems very similar to David Harel's "Statemate" approach to building reactive systems. Have you had a look at his book on the subject, available here:
I-Logix offers an implementation of these ideas in their Statement product: http://www.ilogix.com/sublevel.aspx?id=74
I've never used the product, but I have read the book, and the ideas resonate nicely :) Good luck with your effort.
Thanks for the link. Dr Harel is the inventor of the Hierarchical State Machine that is used in his own systems as well as in the UML specification. He is the man.
What I have been working on, unknowingly for a long time, was ways to simplify a couple of key unresolved issues with his proposed implementations.
The first is the mechanism for behavioral inheritance. Statechart's approach is *very* complex to implement for complicated objects or systems. Software Circuits propose an almost trivial approach that gives you 90% or better of the capabilities.
The second mechanism is the communication protocol from the hand written developer code (called Actions) back to the Software Circuit code. UML and Dr Harel's approach is very wordy and therefore imprecise. Software Circuits require users to summarize their behavior into an integer that can then be used, in a technology independent way, to affect the processing of the Software circuit.
There are other innovations, but those are two of the biggest.
Monday, March 19, 2007
Does this work with Ada, Common Lisp with CLOS , D, Delphi, Dylan, Eiffel, Lua, Objective C, OCaml, Pike, Python, Ruby, Sather, Self, or Water?
Okay, so CL isn't so modern based on release and standardization dates, but by that token neither is C++.
I don't believe that is a quibble, but a very important question. I do not have a definitive answer for you as yet. However, I would make the point that if a particular organization for a class *does* fit into all the languages I mentioned and *doesn't* fit into one of the other languages, it is an interesting commentary on the power of that language. Either good or bad.
It could be good for that language, because possibly the language has a built in superior way to structure classes - better in that it is more intelligible than a State-Oriented approach. Of this I am unaware.
Or it could be bad, because the language just doesn't have mechanisms for implementing states - which I would find very strange, but not impossible - and has no superior paradigm to offer.
But I'm pretty confident it will map to most of those languages.
Sunday, March 25, 2007
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz