How do you design, sketch, and blueprint a complicated piece of software? What are some workflows or tools that can be used to do so? [closed]

Question

I have been programming for a couple of years and am now studying computer-science at university. Every time I have coded something, I did so by starting up my editor and improvise. Writing methods, classes as I go. Off course, I think about it beforehand, I take out sketch paper and write my ideas down, do a little list of things to do, etc. This can work for writing little bits of code or simple and relatively small software, but how about complex ones?

When you want to make a complex piece of software, how do you blueprint it? Architects blueprints a building before starting any real work on it, and they do so by following standards. I expect programmers do to, but I have never heard of it. What are the methods, the tools and the steps that are being used to do so.

I don't want opinions.

I'd like something specific: Charts? Maps? Tools? Techniques? Step-by-steps process? ...

Answer 1

The standard answer nowdays is rather simple: draw UML diagrams.

Back in the years the answer whould have been: "draw flowcharts", "draw Nassi–Shneiderman diagrams", "draw Warnier/Orr diagrams", "draw Data Flow diagrams" ... etc

They would all be good answers and bad answers at the same time. Reality is that there is no single right answer to the question for the simple reason that nobody really knows what software actually is.

Before people jump on my throat, let me explain what I mean.

When an architect creates a blue print of a building, the end product is clear: it will be a physical structure with walls, doors, windows, etc. Our architect will draw a line and say: "this is a wall"; will draw another line and say, "this is the TV-antenna cable from the roof to the basement". Using some convention about dimensions (the scale), colors and types of lines he will be able to communicate to others what needs to be built and how things fit together.

There might be some misunderstanding on the details but nobody will doubt that the 2D model they are looking at, actually represent a building. Even if multiple diagrams are needed (e.g. one per floor) it's rather easy to relate them.

For a software system we are not yet at that level! The first question is "how will you model the software"?

If you use the Object Oriented approach, you will describe your software as a set of "objects" belonging to "classes" that are related to each other (as described in the "class diagram"), with a given behaviour (a "state diagram") and that interact in certain ways (as described in a set of "collaboration diagrams").

There's no single diagram that will show you all the aspects of a software system. That's why UML includes many different types of diagrams.

If you are using a Structured approach, you will describe your system as a set of processing components that transform their input into outputs (a DFD) and as a set data entities (as an ER diagram).

Any diagram will work as long as its meaning is clear to all the involved parties. In fact it's common to start a design session by drawing two boxes on the whiteboard and a line between them saying: "Ok, that's the browser connecting to our web server ...".

The problem lies exactly in what each diagram means.

Actually, we have a good common way of representing the data portion of a system: an entity relationship diagram (or the "static part" of a class diagram) can be directly translated into a live database. I ascribe this to the fact that relational databases are well-founded into the relational algebra and, at the same time, they have use simple concepts that anyone can grasp (tables, foreign keys, join, ...). All the other representation of data have been wiped out (no more hierarcycal database around!).

What we lack is a common, accepted view of the dynamic aspects of software; some unifying view that would be both theoretically sound and not to difficult to use.

That said here is my suggestion.

1. Remember that the minimal purpose of an architecture is to create a common understanding of the system.
2. Learn as much type of diagrams as you can.
3. Use the most appropriate diagram to illustrate the aspect you want to focus on.
4. Provide a way to relate different diagrams (in my experience this is the most neglected aspect and you end up with a bunch of extremely detailed models that do not fit together!!!).
5. Constantly revise the models to reflect the new understanding you gain during the design process.