Bookmark this on Delicious
Recommend to StumbleUpon
I have notes for translators, if you would add a translation. Please note: This "translations" block will be moved to a place further down the page if it becomes extensive.
This page, as it stood in May 2017, is available, translated by humans, into Albanian by Strong Auto.
This page is "browser friendly". Make your browser window as wide as you want it. The text will flow nicely for you. It is easier to read in a narrow window. With most browsers, pressing plus, minus or zero while the control key (ctrl) is held down will change the texts size. (Enlarge, reduce, restore to default, respectively.) (This is more fully explained, and there's another tip, at my Power Browsing page.)
Before I start on something else that I start on before I answer "what is design", a word of warning. This page rambles. It doesn't "tell you what button to press". It doesn't have video clips or pretty pictures. But if you are willing to settle down, and dig in, I think there are things here which you could find valuable.
Some people are content to bump along, with the world we are used to. Others have an itch to change things.
Too much lip service is paid in schools the xxx idea that anyone can do anything, just as long as the want it enough, try hard enough. While I applaud the hopes of teachers to be encouraging, they sometimes lean so strongly to the politically correct, and the "safe" that children fail to understand that while we all have the same basic rights to aspire, and that we should not be denied certain things based on irrelevant criteria, we are also all different. The child with a club foot will never win a footrace against a contemporary born with well coordinated, well functioning limbs.
Not only are we born with different bodies, but we are born with different minds. If minds were food, you might say that one mind is "steak", another "ice cream". Neither is "better". Both are valuable. But it would be absurd to serve ice cream as a main course, or steak for desert. And it must also be admitted that some minds faster than others. Some minds see things more easily that others do.
But it is an over-simplification to say mind "A" is more capable than another. You have to specify a field. I'm a pretty good computer programmer, but I can't read music.
That brings me to one last thing before we get down to what is design,
I said I can program, but can't read music. What I need to add to that is that I've tried quite hard at both. I've also had good teaching in both fields. If you want something badly enough, perspiration can somewhat compensate for inspiration. I knew a boy who was a first class cricket player, despite being blind in one eye. Follow your heart... but try to know something about which roads might be easy for you, which might be a struggle.
So... back to "steak" and "ice cream". Some people were born artists. If they pursue that road, they can learn a lot about the craft of their medium, but to become great, they will also have to "use the force", and draw on their capacity to feel what is going to create beauty.
Some people have talent in relating to others. Maybe they will become counselors, carers, etc, etc.
Some have mechanical aptitude. They are good with their hands.
And then some are good at thinking up machines... in broad terms... which haven't existed before, or thinking of variations on existing machines which will give mankind a new useful device.
These are the designers.
They make things by a scientific approach, rather that the more intuitive approach of the artist. That isn't to say that there is no design in art, or art in design... it is a question of emphasis.
So... what is design? It is a disciplined process of looking at what we require of what we are designing, and looking at the properties and capabilities of the materials and components available to us, as we try to bridge the gap between where we are and where we want to be.
Whether you are designing a mechanical device, an electronic circuit, a computer program, or something else: Keep It Simple
If the job can be done with 5 parts, don't use the design that uses 10 parts. Of course, no one sits at a desk with a 5 part design in one hand, and a 10 part design in the other, and says, ummm, which shall I use. But if you find yourself sitting there with a 10 part design, ask yourself... could I do this with fewer parts?
The simpler something is, the fewer things there are to go wrong.
Of course, it must be fit for purpose. If we were in the same room, I could communicate with you with nothing more than my voice. To communicate with thousands who care to sample my thoughts, across thousands of miles, takes a more complex design. But you may have noticed that even though I am using computers and the internet, the page you are reading has very few "whiz bang" fancy headings, no animated graphics, etc, etc. If I wanted to show you how a four-stroke internal combustion engine worked, I'd use an animated graphic. But that's more than these ideas need.
When you achieve a simple design to a complex design challenge, if you have an engineer's mine, you will know you've done it. To an engineer, their is a beauty in something simple.
In something like a car, the modules are obvious. Other design challenges also yield to the old concept of "divide and conquer". At the top level of a car, you might split things up into...
Taking just one of those, the engine, we can divide the problem again, this is the second level of the hierarchy... We'll pretend our car is to have a gasoline engine. Design of the engine could be broken up into cooling, lubrication, drawing in the fuel/air mixture, providing a spark... etc
Now consider "providing a spark". Where does the electricity come from? How is it delivered to the right place? At right time?
You get the idea? Modules. Hierarchies. And remember: The same principles can be applied to electronic circuits, computer programs, and more.
Later discussions will shed more light on the answer to that, I hope, but let me here claim that with a good modular design, you can work on parts of your design in isolation. And where things aren't quite right, you can improve their design more easily when you can work on modules separately.
I hope that while I was talking about the way you might split up the problem of designing an engine, you were thinking, "Wait a minute... it would be better to split things like..."
A big part of the "art" of design is choosing how you've broken the problem up. What is a "good" scheme? One that gives you modules you can work with in isolation, one amenable to something we are about to talk about: "Top down design/ bottom up development"
How do you go about breaking the problem up so that you will have "good" modules... Ah... a question which is not so easily answered. The more you strive to do it, the better you will get at it... but you have to remember to try!
This principle encourages you to start the design process in broad terms. "Broad" need not be another way of saying "wooly". But start with a clear statement of the project's goal. Continuing the car example, at the very top of the design process you might say "We're creating something to move people at speeds of up to 70 miles per hour, in reasonable comfort, insulated from the environment."
Part of the "trick" of top down development is to keep one eye on where you are going at the same time as you are "using the other eye" to take care of some specifics.
Maintaining the right level of specificity as you work from the upper, more general, levels down to the bottom, highly specific details of each part of a part of a part.... of the design. It is an art, and takes practice. And at the same time, the art of breaking the problem into a useful structure of modules is being exercised.
When you begin to get it right, again, you should feel that things are right. You will feel that you are "on top" of whatever piece of the puzzle you are working on at the moment. Again, "beauty" is not too strong a word. You should see a beauty in the structure. You should be able to read what you have written, and be comfortable that you understand what is going on, and feel that you know "your place" in the overall scheme. If you don't feel this, then continue to work on your design until you have it pretty well "finished", at least in terms of specifying what all the parts will be, how they fit together, what is taken care of by each module, sub module, sub- sub module, etc.
Far better to embark on the next phase... the "bottom up development"... from a scheme which "should" work. Yes, of course you will find "little things" (or maybe not so little things!) that, on reflection, need revision. But the harder you work in the first phase, the fewer of them there will be. And fixing them during the planning is a lot easier than making changes when you've started building modules. For one thing, it avoids the need of going back and revising bits which should have been "done"!
If you are alert, you will from time to time find you've painted yourself into a corner. Annoying, and something you will get better at avoiding, as you get better at the whole process... but it is good if the process lets you see the problem early, which it may. It is hard to avoid doing it, but it is worse if you do it, but don't discover it until late in the building process!
Suppose you were having a house built. That's a design problem. You and your architect would start with a broad, "top level" idea of what you wanted. Together you would develop the design, gradually addressing greater and greater levels of detail. If you've ever been involved in such things, you will know that it is very much better to have the plan finished before you start construction. Even if you have an honest builder, making changes as you go along is a costly affair, because "fixing" things that have to be changed in the plan, after building has commenced is much harder than it would have been to do "it" right, once.
So! You have a brilliant plan. All of the things that could go wrong have been carefully considered and provided for. Everything the project should achieve has been built in. (Right... and my current stock portfolio is perfectly balanced... but we can dream!)
Are you sure??
If so, then it is time to go on to the development phase. But get the "top down design" work properly finished, first, if you want to save yourself grief.
Three things to look out for:
Impatience: Are you itching to "get going"? I hope so! But don't give in to a want for instant gratification if the planning of the work is not truly complete!
Doubts: If you are honest with yourself, is there some little corner of the plans about which you have doubts? To put that a different way, are you totally confident that you cut no corners along the way? If you have got any doubts, you really ought to look under those rocks now.
Worries: Sometimes at this stage there's an element of a design that you are, if you search your soul, secretly a little worried about. Suppose you are designing an electronic circuit, and you need a certain component to tolerate a 500mA current, and you aren't quite sure exactly how high the current there is going to be. Find a way to get the answer now. Don't start the main bottom up development until you know you aren't going to have a problem with that 500mA limitation. Or find a way to go around the limitation. Often you can built little test circuits (or small computer programs, etc... whatever you are designing) to clear up a worry which you have been clever enough to notice and deal with early, thus avoiding having to do complicated backtracking during the development phase.
Once you have the design right, you start on the development. Let's say we're building a new design of car.
Remember we talked of "modules"? The engine is a module in a car, and within that we have modules like the spark plugs, the carburetor, a piston/ connecting rod/ cylinder module.
In bottom up development, we try to work first with sub-sub-sub assemblies. For instance, a spark plug. We built that and test it. (We can't fully test it, of course, but we can make some tests. Will it make a spark, when a voltage is applied? Will it screw into a threaded hole of the size we intend to make in the top of the cylinder? Does it survive being as hot as it will be when the engine is running? The more tests you can think of and run, the better.
Let me digress for a moment to the realm of creating computer programs,
In that realm, modules are easily encapsulated in subroutines. (In some languages, these are "functions" and "procedures".) The more skilled you become at using these, the farther you will go as a programmer. You need to see where to use a subroutine. You need to master "chopping up" your code into subroutines. You need to master your language's facilities for passing data to and from subroutines. And you need to master "nesting" subroutines, in other words building subroutines out of subroutines which themselves are built of subroutines, etc. (Like a hall of mirrors.)
Going back to bottom up development....
We were creating an new sort of car. We'd finished the "top down design".
The principle of "bottom up development...and testing..." requires that we look for sub- sub... assemblies, like the spark plug. We build that, and test it. Then we go on and build other sub- sub- assemblies... wheel, door, carburetor, radio... etc.
Why all the emphasis on testing?
If you test as you go, you won't be left at "the end" (of building the first prototype) with a daunting testing (and tweaking!) phase ahead of you. And....
More importantly, by testing as you go along, you may discover things which require changes which will be easier to make now than it will be to make them later.
In a slightly strained example, let's pretend that we planned for a radio module which is 12cm deep. But when we build the module, and test it, we find that we just can't do it... the module needs to be 15cm deep. What if the way we designed the radio's "home" in the car there isn't room for the deeper radio module? We are going to be rewarded for our testing! We won't build the unsuitable dashboard now. We will redesign it first, to accommodate the extra 3cm that we need.
So... we've built and tested some sub- modules. Next we assemble those into sub-modules, e.g. the engine, and we test again.
Another advantage of the "top down design/ bottom up development" method is that the job usually gets easier as you go along. The early stages are hard, and somewhat boring, work. But as you get closer to the end... if you've done the first parts right... everything "comes together" very nicely.
Frameworks: As you proceed, you may need to build frameworks. In our "make a car" example, when we've got to the stage of assembling the engine from its sub-modules, some sort of framework to mount it in will be necessary before we can do testing. Sometimes you will have other parts of the bottom up development sufficiently far along that you can "mount the engine" in the frame it will eventually go in. Other times, you will make a temporary frame, just for the testing phase.
While such things are, I hope, easy enough to visualize in the case of building a car, maybe they aren't as obvious to readers who will be building software.
In any case, in either case, the building of such frameworks is part of the art of the design process. There are no simple answers. But you gradually become more skilled, as long as you keep trying. Keep in mind the basic requirement: You want to build your product "from the ground up". You want to assemble sub- sub- sub...assemblies first. And test them. Then combine them to build the next level. Test that. Etc. Bottom up.
As you gain skill with the "top down design/ bottom up development" process, you should find more and more that the way you broke the project up during the "top down" phase helps you proceed easily during the "bottom up" phase.
Returning to "frameworks": In the case of building software, where we use subroutines to encapsulate modules, we will often build little scratch programs to "exercise" the subroutines.
Suppose our finished program is supposed to encrypt files, using a user-supplied key.
There will probably be "rules" about the key... must not be too short, must have at least one digit in it, etc.
Again, a slightly strained example, but with some sense in it none-the-less: You will almost certainly have a module called "GetKeyFromUser". During the bottom up development, you might produce a small program, containing what you hope will be the final code of "GetKeyFromUser". The small program would provide a framework for calling the GetKeyFromUser module, and then just popping up a "passes rule tests" or "fails rule tests" message.
Continuing with that a little bit: The subroutine would return two values: A boolean (true/false) which I'll pass to "boPassesRulesTest", and a string, to hold the key, which I'll put in "sKey". (Note: The "tests" here aren't the testing we are doing during our bottom up development. They are the tests the software should apply to the key the user has supplied, to see if it meets the program's requirements... long enough, digit included, etc.)
The framework for testing GetKeyFromUser... and, up to a point, the call's context in the final program... will look something like the following. Actually getting something from the user, in my example, would be built into GetKeyFromUser. The last line below would be as shown for the testing framework, so the design tester can try key after key after key, seeing how GetKeyFromUser responds... and yet still the tester has an elegant way to exit the testing process... by entering 'q' as "the key". In the final program, we'd probably take the "else showmessage('Good key') bit out, and we would certainly change the "until" part... which could be as simple as "until boPassesRulesTest==true". (A flaw in that perhaps over-simple "answer" is that it gives frustrated users no way out when they can't find a key that is acceptable to the program's requirements.)
repeat
GetKeyFromUser(boPassesRulesTest,sKey)
if boPassesRulesTest==false then showmessage('Bad key')
else showmessage('Good key')
until sKey=='q'
So... I hope that makes sense? (Have a quick second attempt, if not, as I'm about to take it a bit further.)
I am still talking about frameworks, and the "bottom up" deve3lopment process.
While you could develop the program that way, if you were a bit more artful, in this case, you might well proceed as follows.
First build the bits of the program around where you will eventually insert the call of GetKeyFromUser. And, while developing those other parts, just put, in place of the GetKeyFromUser, sKey='tempkey123'
That would give you a "working" value for sKey, for testing all the bits of the program which need the key... and allow you to, later, "plug in" the routine which will bring the program closer to the final wants by adding the part which gets a key from the user, rather than just using a "fixed" key.
Be a bit careful, though. If you only test the other parts with one key, e.g. "tempkey123", there may be things in the part you think you are "testing" which work with that, but fail with other valid keys.
Learning "what matters", so you can do effective testing, is another of those areas which demand that you be artist as well as engineer.
That's it for "Bottom Up Development and Testing", and thus we also finish "Top Down Design / Bottom Up..."
(By the way... this essay "built", in some ways, using the principles of "top down design/ bottom up development"! Think how that might be? Some of the techniques your English teacher may have tried to drum into you were just a variation on that.)
Moving on, to finish up by considering two other aspects of "good design". Making things maintainable and making them fail safe.
How many times have you had to throw something out because one small element of it has failed, and that "can't" be mended? I once had to discard an otherwise good laptop because the cooling fan had dies, and couldn't be replaced. Needless to say, I avoid that brand now.
As you develop your design, try to anticipate what parts may fail, and make it easy to service or replace them. There is a reason car wheels are connected to the axles with bolts, not rivets!
Not only should it be possible to replace components, try to put the modules of your design together so that you can disconnect them for testing. The door to my home is locked with a system which releases an electromechanical strike plate when the right RFID tag is brought up to the sensor. The syste3m recently stopped working. Happily, the strike plate module is connected by a plug that mates with a socket. It was easy to unplug the cable and put a voltmeter on the socket, to see if it was the strike plate, or the circuits driving the strike plate which had failed.
Yes... the modules I was just speaking of in connection with maintainability in a design are the same modules that we designed from the top down, and developed from the bottom up.
Remember that Mr. Murphy, him of the eponymous Law, is out there waiting for us.
In grade school, I was taught that the Westinghouse brake was a huge break-through in the development of the railways. Before Mr. Westinghouse's eureka moment, as a "make it fail safe" designer, brakes were used in many things... but you had to activate the brake... and if the mechanism was in some way faulty, well, that was a pity. Too bad you didn't know there was something wrong before you needed the brakes to come on...
Westinghouse's brake takes a different tack. It's almost a bad name. The might better be called "wheel rotation allowers". When something is fitted with Westinghouse brakes, the wheels "ordinarily" won't turn. The brake pads are pressed against the wheels by large, powerful, simple springs. To make the train mobile, first, the pads must be pulled away from the wheels by relatively complex pneumatic actuators. You don't "apply" the brakes... they apply themselves, very simply, in a way unlikely to "go wrong". But... if you want to move, you have to "UN-apply" the brakes. If everything is working correctly, you can move. If something is wrong... if a system has failed... you can't move, and if you are moving, before long you stop.
Mr. Westinghouse looked at the system he was designing a module for. He asked himself what state was least safe. And he designed his brakes so that, in general, when the things that could go wrong did go wrong, the system moved to a safe state, as opposed to the less safe state.
Easy when someone shows you!
What about the thing you are designing? Can you make it "fail safe"? First you have to identify what the "safe" state would be. Then you have to look at the design you have, correctly identify the ways it could fail. For each of them, is the result a safe state?
I've seen several designs for computer controlled electric doors, e.g. the front door of someone's home.
If the electricity fails, what happens? Does the door swing free in the breeze? Probably less than wonderful, in terms of keeping burglars out. But what happens if when the electricity fails the door locks up? Not funny, if you are at home, in bed, and the power has failed because you have a fire in your home. Hmm. Designing for "fail safe" can be quite important.
What about a system to water houseplants? Suppose you hook a small "hose" up to the general water supply, and have an electrically operate valve which is opened when the plants get too dry? Is this really a good idea? What if the system fails at a moment when the valve is open, and you are away from home for the weekend. You'd be amazed how much damage half an inch of water across all of the ground floor rooms in your home will cause. Look around. Who would have thought you had so many things on the floor!
So... What could fail? What state would that leave things in?
Forgive a small digression, meant merely to amuse? In his thriller "Transfer of Power", Fince Flynn imagines a terrorist with a flair for fail safe design. The terrorist has planted bombs throughout the White House. He doesn't want the Good Guys to win. So his bombs will go off if they don't receive a "stay quiet" code every five minutes. Bad Man. Good Designer.
Thank you for taking the time to read this... I hope it has helped you become a better engineer, whether you are building physical things like electronic circuits, or more abstract things like computer programs or databases. The principles set out above of good design apply across many disciplines.
|
|
If you visit 1&1's site from here, it helps me. They host my website, and I wouldn't put this link up for them if I wasn't happy with their service. They offer things for the beginner and the corporation.
Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org
....... P a g e . . . E n d s .....