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

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

Phosphorous

Answer 1

• 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.

Devon

Most helpful response, I wished you had got more upvotes. – Phosphorous

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.

Sammie

I think the old fashioned pen and paper will never go away from my toolbox no matter what they'll come up with ... – Selfpropulsion

Answer 3

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

Kerry

+1 for WML. My preferred route as well. – Townes

That's a tool - the OP wanted to know what type of diagrams do you use. – Oho

@DJ, "whiteboard modeling language" is right there in my answer. Did you miss that? – Kerry

The type is whatever fits legibly on a white-board. The tool and the diagram aren't mutually exclusive in this case. – Prothalamion

Probably "bubble-box-line" diagrams, just like me :) – Sammie

@Out in space - sorry missed the joke :-) – Oho

@eric p, I also draw stick figures. – Kerry

@Out Into Space - I didn't know stick figures were available. That must be part of the 1.1 version of the spec. – Sammie

I like this idea, 'Out of Space' would you publish a spec for me, Thanks – Phosphorous

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.

Isomorph

Answer 5

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.

Indies

Answer 6

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.

Southeastwardly

Answer 7

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."

Rimola

Answer 8

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...

Prothalamion

Answer 9

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.

Banian

I liked the ordering and process, Thanks! I to want tested and working code for posterity – Phosphorous

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.

Caffey

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'] }

Foremost

Answer 12

I like Data Flow Diagrams. A lot.

Wits

Ben, What do you like about DFDs? – Phosphorous

Their simplicity. Anyone can see what's going on with a DFD even if they're not familiar with the notation. They encourage a hierarchical breakdown of data flows and processes in a system, encourage encapsulation etc. They can be used effectively in both design of new and documentation of existing systems. A lot of what we do is simply moving data around and performing transformations on it. DFDs are an ideal way of describing this at a high level. – Wits

Answer 13

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.

Nalepka