lecture-20.Design-Strategy - Lecture 20 Design Strategy This lecture puts together some of the ideas we have discussed in previous lectures object

lecture-20.Design-Strategy - Lecture 20 Design Strategy...

  • Ryerson University
  • COE 618
  • Notes
  • Pakistani
  • 12
  • 100% (1) 1 out of 1 people found this document helpful

This preview shows page 1 - 2 out of 12 pages.

122 Lecture 20: Design Strategy This lecture puts together some of the ideas we have discussed in previous lectures: object models of problems and code, module dependency diagrams, and design patterns. Its aim is to give you some general advice on how to go about the process of software design. I’ll explain some criteria for evaluating designs, and give a handful of heuristics that help in finding a design to solve a given problem. 20.1Process Overview & Testing The development process has the following major steps: · Problem analysis: results in an object model and a list of operations. · Design: results in a code object model, module dependency diagram and module specs. · Implementation: results in executable code. Testing should ideally be performed throughout the development, so that errors are found as soon as possible. In a famous study of projects at TRW and IBM, Barry Boehm found that the cost of fixing an error can rise by a factor as great as 1000 when it is found later rather than earlier. We’ve only used the term ‘testing’ to describe evaluation of code, but similar techniques can be applied to problem descriptions and designs if they are recorded in a notation that has a semantics. (In my research group, we’ve developed an analysis technique for object models). In your work in 6170, you’ll have to rely on careful reviewing and manual exercise of scenarios to evaluate your problem descriptions and designs. As far as testing implementations goes, your goal should be to test as early as possible. Extreme programming (XP), an approach that is currently very popular, advocates that you write tests before you’ve even written the code to be tested. This is a very good idea, because it means that test selection is less likely to suffer from the same conceptual errors that tests are intended to find in the first place. It also encourages you to think about specs up front. But it is ambitious, and not always feasible. Instead of testing your code in an ad hoc way, you should build a systematic test bed that requires no user interaction to execute and validate. This will pay dividends. When you make changes to code, you’ll be able to quickly discover fresh bugs that you’ve introduced by rerunning these ‘regression tests’. Make liberal use of runtime assertions, and check representation invariants. 20.2Problem Analysis The main result of problem analysis is an object model that describes the fundamental entities of the problem and their relationships to one another. (In the course text, the term ‘data model’ is used for this.) You should write short descriptions for each of the sets and relations in the object model, explaining what they mean. Even if it’s clear to you at the time, it’s easy to forget later what a term meant. Moreover, when you write a description down, you often find it’s not as straightforward as you thought. My research group is working on the design of a new air-traffic control component; we’ve discovered that in our object model the term Flight is a rather tricky one, and getting it right
Image of page 1
Image of page 2

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture