Introduction to Software Construction

1. Introduction to Software Construction Chapter 1-3

2. What Is Software Construction?

3. What we will cover?

4. Why Is Software Construction Important? • Is a large part of software development • Is the central activity in software development • With a focus on construction, the individual programmer's productivity can improve enormously • Construction's product, the source code, is often the only accurate description of the software • Construction is the only activity that's guaranteed to be done

5. The power of metaphors • The chemist Kekulé had a dream in which he saw a snake grasp its tail in its mouth. • When he awoke, he realized that a molecular structure based on a similar ring shape would account for the properties of benzene. • Further experimentation confirmed the hypothesis

6. Software Metaphors • Metaphors have the virtue of an expected behaviour that is understood by all.   • unnecessary communication and misunderstanding are minimized, • allows for quicker learning and a higher level of abstraction for the problem at hand. • A software metaphor • is more like a searchlight than a road map. • it doesn't tell you where to find the answer; • it tells you how to look for it. • A metaphor serves more as a heuristic than it does as an algorithm. • a heuristic process. • This will tell you how to look for a solution, not where to find • an algorithm process. • Gives you specific directions for a solution, and where to look to find the solution.

7. Heuristic vs. algorithm • The main difference • the level of indirection from the solution • example: Getting to someone's house • Heuristic • Find the last letter we mailed you. • Drive to the town in the return address. • When you get to town, ask someone where our house is. • Everyone knows us—someone will be glad to help you. • If you can't find anyone, call us from a public phone, and we'll come get you. • Algorithm • Gives you the instructions directly – GPS

8. Common Software Metaphors (1) • Software Penmanship: Writing Code • looks at writing software the same way that most people think that an author writes a book.  You just sit down and start writing from start all the way through to the finish. • along with starting from scratch, just as in writing a story, expect to take at least one version of your program and completely through it away. • this works great if you are working for yourself, however, most employers like to see productive work, not work you throw away. • implies a software-development process that's too simple and rigid to be healthy

9. Common Software Metaphors (2) • Software Farming: Growing a System • like planting seeds and growing crops • You design a piece, code a piece, test a piece, and add it to the system a little bit at a time. By taking small steps, you minimize the trouble you can get into at any one time • a good technique is described with a bad metaphor • its suggestion that you don't have any direct control over how the software develops.

10. Common Software Metaphors (3) • Software Oyster Farming: System Accretion • like a oyster gradually adding coats of calcium carbonate to a pebble to reduce the irritation. • make the simplest possible version of the system that will run  • it doesn't have to perform realistic manipulations on data, it doesn't have to produce realistic output • however, once the version is complete, we slowly add small working components to the system and test them.   • will eventually lead to a fully functioning system by slowly over time adding little bits of working code to make the operation smooth and pretty.

11. Common Software Metaphors (4) • Software Construction: Building Software • The image of "building" software is more useful than that of "writing" or "growing" software. • It's compatible with the idea of software accretion and provides more detailed guidance. • Building software implies various stages of planning, preparation, and execution that vary in kind and degree depending on what's being built.

12. Building houses vs. building software • In building a house, you won't try to build things you can buy already built. • You'll buy a washer and dryer, dishwasher, refrigerator, and freezer. • Unless you're a mechanical wizard, you won't consider building them yourself. • You'll also buy prefabricated cabinets, counters, windows, doors, and bathroom fixtures. • If you're building a software system, you'll do the same thing. • You'll make extensive use of high-level language features rather than writing your own operating-system-level code. • You might also use prebuilt libraries of container classes, scientific functions, user interface classes, and database-manipulation classes. • It generally doesn't make sense to code things you can buy ready-made.

13. The Intellectual Toolbox • A good craftsman • knows the right tool for the job and knows how to use it correctly. • A good programmer • The software practices and techniques that work become the toolbox.   • add what worked as well as what didn't work to the toolbox to make it more effective

14. Prerequisites to Construction • Before beginning construction of a house, a builder reviews blueprints, checks that all permits have been obtained, and surveys the house's foundation. • A builder prepares for building a skyscraper one way, a housing development a different way, and a dog-house a third way. • No matter what the project, the preparation is tailored to the project's specific needs and done conscientiously before construction begins. • As with building construction, much of the success or failure of the project has already been determined before construction begins. • If the foundation hasn't been laid well or the planning is inadequate, the best you can do during construction is to keep damage to a minimum. • The importance of these steps cannot be overstated. • if this process is poorly done, we will still be lucky if the result is even working, let alone useful

15. Emphasizing Quality • At the end of the project • emphasis is on testing • In the middle of the project • emphasis is on good construction practices • At the beginning • plan for a high quality product • Your design limits the end results. • by the time you start construction, it is too late to correct a weak or faulty design. • The best we can do in construction is to recognize that the design is bad and go back and try again.   • However, this can be an very expensive proposition, but at times necessary to actually save money.

16. Cost to fix defects (1)

17. Cost to fix defects (2)

18. Problem-Definition Prerequisite • The problem definition lays the foundation for the rest of the programming process • you need a clear statement of the problem before you can even think of a solution • the problem definition must also be general enough that it does not presuppose a solution • the definition should be in the user's language and from the user's point of view • the solution may turn out to be something that is not related to computers at all

19. The penalty for failing to define the problem

20. Requirements Prerequisite • Ensure : • The user's needs are driving the system, not the programmers • System scope is agreed upon • Minimal changes will be needed after construction begins • since requirements are never stable: • use the checklist on pages 33-34 of your text. • make sure that the cost of changes is understood • establish a good "change control" procedure • use an approach that accommodates changes • lastly you can always kill the project.

26. Without good requirements • you can have the right general problem but miss the mark on specific aspects of the problem

27. Architecture Prerequisite • Buy versus build (market research) • System architecture • why was a particular architecture chosen? • what things did we consider when we made our choices? (Cover your own butt) • Major data structures • Functionality • Key algorithms that are present in the user requirements • User interface • Hardware requirements • Nonfunctional • Error processing • Robustness • Over engineering • Fault tolerance • Performance • usually means the average response time, which is system dependant • Strategy to handle changes

28. Without good software architecture • you may have the right problem but the wrong solution. It may be impossible to have successful construction

34. Key Construction Decisions • Choice of Programming Language • Programming Conventions • Your Location on the Technology Wave • Selection of Major Construction Practices

35. Choice of Programming Language

36. Programming Conventions • Allows for more productive coding between programmers on projects, as it provides a common platform from which the system is built. • Before construction begins, spell out the programming conventions you'll use. Coding-convention details are at such a level of precision that they're nearly impossible to retrofit into software after it's written.

37. Your Location on the Technology Wave • Programmers who program "in" a language • limit their thoughts to constructs that the language directly supports. • If the language tools are primitive, the programmer's thoughts will also be primitive. • Programmers who program "into" a language • first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language. • Most of the important programming principles depend not on specific languages but on the way you use them

38. Selection of Major Construction Practices