I’ve set myself the task of implementing a real time MIDI application. Like all the other software I’ve written to date, I began by coding. I implemented a tiny GUI (GTK2) application that can control the transport state of the Jack Audio Connection Kit and its clients.
I have never written a real-time application before, and have only ever written one multi-threaded program. Both of these details combine to make this a substantial challenge for me as all the software I have written to date, has not required me to design it first. I’ve only occasionally needed a pen and paper to work things out.
This project however, won’t let me proceed by coding. But I know next to nothing about software design, I am self taught (discounting a 2 yr computer studies course in the mid 1990s). I’ve always worked stepwise, getting something working and then building upon it.
During my research I’ve come across the Model View Controller pattern but I’m finding it really difficult to not think about details, and can’t find any foundation to build upon without finding problems which bring it all tumbling down.
I need advice to get past this block. I need to stop finding distractions which loose my train of thought. This is one of the distractions. How do I get past this block?
In very broad terms, “software design” is the process in which you decompose the problem at hand in a series of module, and specify what each module responsibility are, and how each module should communicate with the other modules (if at all).
There are various ways to proceed with this activity. Considering this would be your first attempt at it, keep things as simple as possible: grab some paper sheets and a pen.
First step: write down a list of tasks that your new application must be able to execute.
After this try to group the tasks in different sets that you think belong logically together.
For each subset, find a name, write it on blank sheet (one for subset) and describe what the module does in a little more detail, including which type of data it should work on and/or exchange with others. Each of these is a “module design paper”
On another blank sheet draw a box for each subset, label it with the proper name, and try drawing arrows from one box to the other, each arrow should have a name and represents one of your module calling another. Let’s call this your module “interface design paper”.
Double check your modules description with the interfaces they should offer to other modules, and see if this requires change to the original task list and how this affects the data they manage.
Modules can be subdivided iteratively if they look too complex/big to you. Just draw another interface design paper if you split a module in submodules, and remember that the sum of the submodules should be able to carry on all the tasks you had originally envisioned for your module, and be able to answer the requests of the rest of the system.
See also CRC cards for more detail.