How do you plan an application's architecture before writing any code?

Question

One thing I struggle with is planning an application's architecture before writing any code.I don't mean gathering requirements to narrow in on what the application needs to do, but rather effectively thinking about a good way to lay out the overall class, data and flow structures, and iterating those thoughts so that I have a credible plan of action in mind before even opening the IDE. At the moment it is all to easy to just open the IDE, create a blank project, start writing bits and bobs and let the design 'grow out' from there.I gather UML is one way to do this but I have no experience with it so it seems kind of nebulous.How do you plan an application's architecture before writing any code? If UML is the way to go, can you recommend a concise and practical introduction for a developer of smallish applications?I appreciate your input.

Answer 1

I know you say you don't want to begin at "gathering requirements to narrow in on what the application needs to do", but I think that's where you should start to determine the architecture of your application. The way I always guide my students in my classes is to ask them to write down the following components on a sheet of paper first before coding anything:

INPUT

CALCULATION

OUTPUT

Why? Because any solution you need to code will require these 3 components:

INPUT - this component shows what you are given to start with or need to get from the user of your applicaton. This should be step 1 in your thinking on the architecture (same as what you say earlier as "gathering requirements").

OUTPUT - this component determines the result the problem asks you to solve and show. This should be step 2 in your approach so you know what to output.

CALCULATION - this component involves all the calculations that you need to do to link your input to your output. Basically, it includes all the steps that you need to do to use your input information, calculate or manipulate the data, so you can generate the output you want. This should be step 3 in your application's architecture design.

Use the components to guide you on your design. Under each component, fill in the appropriate information (in the order mentioned above). Once done, you should have the clear logic flow in place on how your application works. Then, you can group the steps to do into smaller "units of work". By unit of work, I mean you should group related tasks together so you can convert them into actual programming code. These tasks can be in the form of function, structure, class, etc. The UML that you talk about above are actually nothing more than grouping these units of work, where each unit contains the data and functions that will serve some common purpose (like a Rectangle class to contain length and width data as data members and have methods to calculate the perimeter or area based on these data members), and should be used when you get to this point.

So, to recap, I recommend you start with a very high level logic flow on how to solve the problem first (using the INPUT-CALCULATION-OUTPUT mentioned above). Then, look for similar tasks that should be grouped together and create a work unit out of them. Next, get these units of work to "call" each other that match the logic flow that you have laid out. Once done, you can then bring up your IDE and start writing actual programming code as laid out by these units of work. Remember, putting an UML together is just a different way of linking your units of work together but it won't help you with your high level logic flow. Personally, a UML drawing is best used in a team environment but not as a one-person project. Drawing things on a sheet of paper is just as effective as designing an UML diagram using a tool. Also, coding should be done ONLY when you have an idea what you are trying to accomplish. Otherwise, you will continue to code "bits and bobs" here and there and waste a lot of time putting your design together. Hope my guidance helps.