What diagramming techniques (not tools) do you use during your programming?

Question

What diagramming technique(s) do you use while programming to help you or others understand your program or design. I am not talking about a person's favorite tool, though a good tool probable helps a person greatly with diagramming.

My intent in this question is to find the simple useful diagramming techniques people actually use and find new ones to learn.

Do you use flow-charts, Data Flow Diagrams, ER diagrams, etc?

The web is full of recommendations! But what do real programmers, designers, and code maintainers actually use in their day to day work.

Thanks for your feedback

Answer 1

I have a Flow chart of the main product I work with and develop.

My team also often uses UML diagram sketches on white-boards while designing new parts for us to implement. They're very useful in creating design patterns and modeling the high-level structure of the classes which will be needed. These are never full blown UML though...

Answer 2

What do we really use? Maybe other people actually create formal diagrams, but for the most part I just scribble bubbles, boxes and lines on a sheet of paper.

Answer 3

I use a whiteboard for modeling, so I guess "whiteboard modeling language" would be my answer.

Answer 4

I will do a UML Class diagram for anything i'm designing that is bigger than a couple of classes. Drawing a class diagram makes me take time out to think over the design instead of ploughing straight into the code and always produces a better result.

For bigger and more complicated architectures I find that Sequence diagrams are a good way to communicate behviour, especially for multi-threaded systems.

Answer 5

I use whatever is needed for communicatation. Usually that's nothing at all. Sometimes it's a whiteboard.

From time to time, I use Sparx Enterprise Architect, which is a UML modeling tool, though it produces decent diagams while it's at it. I've used it for requirements, use case, activity, sequence, domain, and even class modeling, and sometimes some reverse-engineered ER diagrams. Whatever it takes to get the point across.

Answer 6

I use diagrams as a way to quickly understand legacy code. It takes some work to create the diagram, but it always pays of in the end.

Normally I use class diagrams to get the big picture. Sometimes sequence diagrams and even dataflow diagram if a piece o code is extremely hard to understand.

In the design phase I use class diagrams, and often state diagrams. State diagrams are perfect if a class behaviour differs with its state.

Answer 7

Whiteboard for discussions.

Pen and paper for less temporary record.

Code stubs for 'Things to impelement'.

Tested and Working code (with extensive comments) for posterity.

Answer 8

I use Sequence Diagrams a lot (drawn on paper). I find they give me a nice visual representation the logical flow of method calls and information between various systems and components in our applications.

Answer 9

I use ER and class diagrams on paper and whiteboard for any project that's bigger than a shell script.

Flow charts, only when I need to explain a process to a non-programmer (or if it's a really complicated process and I need to understand it first).

My old boss used to say "the guy just loves drawing stuff."

Answer 10

I draw bastardized versions of UML class, object and sequence diagrams. While I try to be true to the syntax, I am much more concerned about expressing the main idea behind particular feature. So, I'll draw up something, ask a colleague to take a look, and if it seems clear enough, we might even scan it and post it in our Wiki.

Then, when it so happens that we actually get some time to work on the documentation (and that is almost never), I'll use BOUML and redraw the scribbles into a proper diagram.

Now, to put is all in context, I'm working at a relatively small team (5 developers), making trading and product configuration platforms in Java. We have our two products that we then additionally customize to customer's requests. Being a close-knit community, with low (zero) turnaround for a few years, we use the documentation primarily as a remainder to ourselves. And in this setup, the above approach works quite well.

Answer 11

I work in an AJAX development environment, and most of the backend code I write works like a pipe between a relational database and the frontend javascript (user interface). So, the most used 'diagram' per say that I use are JSON objects to describe how data should be passed back and forth between the database and the interface. They are simple, universal and easy to understand data structures.

Example:

{ "id": row['id'], "name": row['name'], "mandatory": row['mandatory'], "rangeDescription": "This is the Range", "globalRate": row['global'] }

Answer 12

• Very High Level Discussion - Context Diagrams where the boxes might represent classes, packages, or sub-systems.
• High Level Design - Sequence diagrams which show the interface between sub-systems, still no classes directly used but may be implied from this.
• Detailed Design - Sequence diagrams which are at the class level.

If there is a tricky algorithm for something such as the correlation of multiple data streams into a new stream then I will generally use a Flow Chart to work out the algorithm.

If the solution requires knowledge of state then a State diagram is also used.

Those are the ones I use most.

When doing Data Warehouse design I draw Star Schemas to work out how to store the data. When doing Transactional DB design I use Entity Relationship diagrams to work our data storage.

When designing a UI I just sketch it out. Once I start to get some parts of the UI worked out and want to play with some areas I will make a template, print out a copy copies and then use that as a guide to work on sub-sections. For colour schemes, it can be handy to make a graphic using the gimp and have layers for each piece of the design and then play with the layers colouring each one to find the right balance.

Answer 13

I like Data Flow Diagrams. A lot.