Software design by pseudocoding?

Question

Do you know a good way to design (i.e. write down) software with a method based on pseudocode?

I'm new to software design and read some information about UML. My humble class hierarchies are good so far, however, after it gets complex I notice that with "seeing the whole" picture I could have used a different structure for more future extendability. As Python is good to prototyping I'm almost fine with just starting to write, but not quite.

So I tried UML class diagrams, but they don't seem to help me much. The problems I solve there I can trivially do in my head. But I do notice additional design requirements once I start to pseudocode the actual methods.

So if you wanted to design by pseudocode, how would you do it? I believe for me a method which is roughly 1-to-1 with code works best. But most UML software doesn't even show the method's code (as opposed to pictures in e.g. GoF).

Someone claimed UML is for documentation and presentation only and not that great for design? I also get that feeling. I thought pure UML and some simplistic whiteboard sketches were the way to design software until googling I found Envision APDT.

So is agile development something I should look out for or do they randomly call that agile - I thought agile is about schedule only? Or am I designing incorrectly (with UML) - does anyone design by pseudocode? How can I find a good tool for that?

Answer 1

 I thought agile is about schedule only?

It is not just planning. Agile software development is more about being a evolutionary development and a time-boxed iterative delivery with adaptive planning which encourages flexible response to changes requested by product owner.

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

In my experience charts are much easier to understand from a client stand perspective. They are visually appealing and many times very colorful and easy to follow. However, it is very hard to maintain charts due to the nature of disconnect with the actual application code. Every time a change is made in the application the developer has to take the time to update all documentation including charts. However, that problem can be easily eliminated once there is a BA in the team or company, who understands client business process well and can manage the UML diagrams.

Tools like UML can make this process easier but only works well with object oriented programming. Pseudo code is much easier for technical teams. The process of creating this code greatly increases the speed of the actual programming language development phase.

There are some other alternatives that you may look as well:

• Data Flow Diagrams
• State Diagrams
• Process Flow Charts

Good references to look: Software Design Tutorials. In addition, i would personally advice to read a good blog on Pseudocode or Code? posted by Coding Horror - my favorite blog to read :)

All in all, there are some trade-offs that you need to consider.

Answer 2

When programming in assembly language, writing pseudo-code makes a lot of sense. The algorithm could be verified before expending the effort to manually translate it to assembly language and then debug the translation. It still made some sense for first-generation compiled languages like FORTRAN IV, where the only control construct was GOTO, all variables (except formal arguments) were global, and variable names were limited to six characters.

Today we do very little programming in assembly language, and I see little value in writing pseudo-code instead of just writing code. In a decent language, the actual code will follow the pseudo-code almost word for word, and the pseudo-code is just a waste of time.

However, I don't start coding at the bottom. I follow TDD and start with a test. Then I start coding at the top, and gradually work my down to the bottom as needed to get the tests to pass.

The alternative to pseudo-code is not writing 1000 lines of low-level classes. Instead start at the top, calling the ideal but non-existent API for your domain. Then build the API.

Answer 3

I find class diagrams to be barely worth the effort, even when you skip listing all the methods and simply show the inheritance hierarchy. Sequence diagrams are good, but feel awkward when I'm drawing them (probably just me).

I find data flow diagrams and structure charts to be more useful (although structure charts are commonly associated with BDUF and are therefore out of favor at the moment). DFDs are especially useful for functional decomposition. Each "bubble" in a DFD can be broken down into its own DFD until you get to whatever level of detail you want.

Answer 4

I think graphical tools are better than pseudocoding, but UML is simply so much overcomplicated that it combines the bad in those methods :-)

To be a bit more clear: I think programming is mostly a way to analyze a certain problem, separate it to smaller components and their interaction. This is "a journey, not a destination", you constantly improve your knowledge about the problem, so the graph of components is changing: layers appear and fade away, functions and data items move up and down, etc.

The natural tool to follow this process is a sketchboard, as simple as possible, but enough complex to help quick understanding (same colors, shapes, arrows for the same logical meaning). I have not found the silver bullet, and perhaps I will write my own one day, but now I use gliffy; combined with the zooming feature of prezi it would almost be perfect.

Why not pseudocoding? Pseudocoding is one step forward to implementation, a "serialized form of the component graph", when you yet shape your ideas. Not good, limits your head. In my experience I found that the later I start coding, the less code I have to throw away...

But perhaps this is because I have written all those thrown out codes, so I don't have to write them now, the experience I gained from them is with me when designing the system? Well, I have to modify the statement.

If you are lost with your graph, and see many equivalent possible solutions, do go to pseudocode, or even do write that code with mock objects - in Java, that is almost no difference. See the code, feel the structure and usability of those components, it will help you fixing your graph and make decisions. But this works ONLY if you are ready to throw away that code if you feel it is bad. I think this is the advantage of pseudocode: the less temptation for keeping it when it works, but it is wrong in structure (and as always, you don't have enough time). :-)