How do you design, sketch, and design complex software? What are some workflows or tools you can use to do this?

Question

I have been programming for a couple of years and am currently studying computer science at the university. Every time I encoded something, I did this by running my editor and improvising. Writing methods, classes, as I go. Of course, I think about this in advance, I take the sketch paper and write down my ideas, make a small to-do list, etc. This may work for writing small pieces of code or simple and relatively small software, but what about complex ones?

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

I do not need opinions.

I need something specific: charts? Cards? Tools? Methods? Phased process? ...

Answer 1

The standard answer is pretty simple right now: draw UML diagrams.

In those years that were answered: "draw flowcharts", "draw Nassi-Schneiderman diagrams", "draw Warnier / Orr diagrams", "draw data flow diagrams" ... etc.

All of them will be good answers and bad answers at the same time. The reality is that there is no single right answer to the question for the simple reason that no one really knows what the software really is .

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

When the architect creates the blue font of the building, the final product is clear: it will be a physical structure with walls, doors, windows, etc. Our architect draws a line and says: “This is a wall”; justify one more line and say: "this is the TV antenna cable from the roof to the basement." Using some convention on the sizes (scale), colors and types of lines, he will be able to communicate with other people, what needs to be built, and how everything fits together.

There may be some misunderstanding in the details, but no one doubts that the 2D model they are looking at is actually a building. Even if you need several diagrams (for example, one per floor), it is quite easy to link them.

For a software system, we have not reached that level! The first question is, "How will you simulate the software"?

If you use an object-oriented approach, you will describe your software as a set of “objects” related to “classes” that are related to each other (as described in the “class diagram”) with the specified behavior (“state diagram”) and which interact in a certain way (as described in the set of “collaboration diagrams”).

There is no single diagram that will show you all aspects of the software system. This is why UML includes many different types of diagrams.

If you use the Structured approach, you will describe your system as a set of processing components that convert their input to outputs (DFD) and as installed data objects (in the form of an ER diagram).

Any diagram will work until its meaning is clear to all parties involved. In fact, it’s usual to start a design session by drawing two squares on the blackboard and a line between them: "It's good that the browser connects to our web server ...".

The problem is exactly what each chart means.

In fact, we have a good general way of representing a part of the system data: an entity relationship diagram (or the “static part” of a class diagram) can be directly transferred to a live database. I attribute this to the fact that relational databases are well founded in relational algebra and at the same time they use simple concepts that anyone can understand (tables, foreign keys, joins, ...). All other data representations were destroyed (there is no longer a hierarchical database!).

We lack a generally accepted understanding of the dynamic aspects of software; some kind of unifying view, which would be theoretically substantiated, and not difficult to use.

Here is my suggestion.

• Remember that the minimum goal of architecture is to create a common understanding of the system.
• Find out as many chart types as possible.
• Use the most appropriate chart to illustrate the aspect you want to focus on.
• Provide a way to link different diagrams (in my experience, this is the most neglecting aspect, and you get a bunch of extremely detailed models that don't fit together !!!).
• Constantly review models to reflect the new insights you gain during the design process.

Answer 2

Architects plan to build the building before embarking on any real work on it, and they do it following standards.

This is because with many fields there is exact knowledge in advance. What includes, what are the rules, what are the laws of physics, what rules should be considered. That's why you can prescribe everything to the last nail.

With software, this is very different. You can do what you want. You can achieve anything, and no one can tell you that it is good or bad. Because there are no standards. Only subjective opinion.

Every time I encoded something, I did it by running my editor and improvising. Writing methods, classes, as I go. Of course, I think about this in advance, I take out the sketch paper and write down my ideas, make a short list of things, etc.

As usual, this is done. Before starting a project, you can experiment with some frameworks, tools, and architecture. For example, do some test projects to find out what you need to try to “prepare” your future software.

I do not need opinions.

Each answer here will be an opinion. Because there are no standards from which to return. Experience and opinion.

I need something specific: charts? Cards? Tools? Methods? Step by step process?

What works the most:

• Engage users from the start in your project. Gather regular feedback to customize your course.

• Be flexible and follow some iterative process. First, you outline the user interface. Get feedback. Then you implement some common functions. Receive feedback. Adjust the course. Perform a few more functions. And so on. Sooner or later there will be enough meat to go v.1.

If you absolutely need some strict recommendations, use UML (Unified Modeling Language) for charts and diagrams and use RUP (Rational Unified Process) or its analogues. You can follow Scrum , there are also some organizational activities ivolved.

Answer 3

Firstly, I like Mind-Maps to visualize what this section of the software should do and what are the corresponding limitations (technology, performance, integration points, etc.). I like to use FreeMind (OSS) for this purpose. I think that there is a big difference between talking about requirements and recording them, because the latter makes you think about them more accurately. Especially if you are not familiar with the problem domain.

By the time I am done with this, I usually have a pretty good plan of things in my head and start coding right away. If not, I start drawing things on paper in pseudo-UML notations. UML is a modeling language specifically designed for this purpose. It defines common visual representations for classes, methods, interaction flows, etc. This is not uncommon, your design will change slightly over time, as your understanding of the problem increases as you write code. It is important not to be shy to adapt your design every time this happens.

Depending on the size of the model you want to model, it may be useful to use the UML tool. But usually they are very strict and inflexible. Especially when I decide to redesign my code, my UML diagrams go out of sync very quickly. I really like Visual Studio Class Designer because it works the other way around, I can drop its code and it creates a visual (simple UML) representation.

Answer 4

You probably should give a lecture on software development if you are interested in developing and developing software.

Other answers have already given some hints with this respect; however, an important aspect that should not be neglected is that before you start designing, you should actually write down what your software should do, in the form of software requirements specification :

The specification of software requirements is a complete description of the behavior of the system developed. It includes a set of tool cases describing all interactions with software users. Use cases are known as functional requirements. In addition to use cases, SRS also contains non-functional (or optional) ones. Non-functional requirements requirements that establish restrictions on design or implementation (such as the development of technical specifications, quality standards, or design restrictions).

Such a document helps you focus, clearly identify actual use cases, find possible shortcomings, identify specific goals (for example, regarding performance). The specification will also be the basis for checking your final implementation (does your software do what it should do?) And help you create test scripts.

Answer 5

My "step by step" process will be as follows:

• Create a prototype. This does not need to be done much; in many cases, dragging and dropping several controls on the form designer will do. Then go through the prototype with the client / end user. (This is an important part - if you just create a prototype and throw it through the wall, it will not do any good.) Explain how you think the software will work when you show the prototype and listen to what the client says. Again, listening is more important than explanation. After that, you should have a clear understanding of what the client needs.
• Now I usually take out the paper and pencil and start drawing the structure of the high-level module. Perhaps also important classes, but not every last implementation detail. After this step, I know which modules I need, what is the responsibility of each module, how can I test each module.
• Implementation is done as you know it (at least I do it more or less the way you describe it). But first, you only implement the core core functionality. Otherwise, you should skip critical functions because you are too busy adding bells and whistles.
• Rinse and repeat: now you have a program with limited functionality, return to your client, show it, let them play with it. See how they try to use it: where do they fail? What are they looking for and cannot find?

Tip: Release It