1 / 40

Introduction to Software Construction

Introduction to Software Construction. Chapter 1-3. What Is Software Construction?. What we will cover?. Why Is Software Construction Important?. I s a large part of software development I s the central activity in software development

chen
Download Presentation

Introduction to Software Construction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

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

  22. 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

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

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

  25. Choice of Programming Language

  26. 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.

  27. 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

  28. Selection of Major Construction Practices

More Related