Introduction to Software Design

1. Introduction to Software Design EE 312 Software Design and Implementation I

2. Software Engineering • Goal • Production of software that is effective and reliable, understandable, cost effective, adaptable, and reusable • Because of the long lifetime many people will be involved • Creation • Debugging • Maintenance • Enhancement • Two-thirds of the cost is typically beyond creation

3. Design Principles • Abstraction • Encapsulation • Modularity • Hierarchy

4. Abstraction Encapsulation Modularity Hierarchy Determine the relevant properties and features while ignoring nonessential details Principles

5. Abstraction Encapsulation Modularity Hierarchy Separate components into external and internal aspects Principles

6. Abstraction Encapsulation Modularity Hierarchy Construct a system from components and packages Principles

7. Abstraction Encapsulation Modularity Hierarchy Ranking or ordering of objects Principles

8. Abstract Data Types (ADT) • A specification of a set of data and the set of operations that can be performed on the data. • Independent of concrete implementation • Uses defined interface • Hides details from the user (information hiding) • Not the same as a data structure

9. ADT Example -- Stack • bool empty() • Tests if this stack is empty.   • E peek() • Looks at the object at the top of this stack without removing it from the stack. • E pop() • Removes the object at the top of this stack and returns that object as the value of this function.   • push(E item) • Pushes an item onto the top of this stack.

10. Why? • Allows implementation to be changed without violating ADT definitions • Gives a standard list of structures to use and study • Building blocks and tools • Foundation for OOP • Abstraction, Encapsulation, Modularity, Hierarchy

11. Object-Oriented Design • Purpose • Promote thinking about software in a way that models the way we think and interact with the physical word • Including specialization • Object • Properties or attributes • Behaviors

12. Programming • Class • Term for a type of software object • Object • An instance of a class with • specific properties andattributes

13. Programming • Problem solving through the use of a computer system • Maxim • You cannot make a computer do something if you do not know how to do it yourself

14. Problem Solving Process Determine Analysis problem features Rethink as appropriate Describe objects Design and methods Produce the Implementation classes and code Examine for Testing correctness

15. Tips • Find out as much as you can • Reuse what has been done before • Expect future reuse • Break complex problems into subproblems Find out what is known about the problem Talk to the presenter Determine what attempts have succeeded and what attempts have failed

16. Preconditions and Postconditions Frequently a programmer must communicate precisely whata function accomplishes, without any indication of how the function does its work. Can you think of a situation where this would occur ?

17. What are Preconditions and Postconditions? • One way to specify such requirements is with a pair of statements about the function. • The precondition statement indicates what must be true before the function is called. • The postcondition statement indicates what will be true when the function finishes its work.

18. Example void write_sqrt( double x) // Precondition: x >= 0. // Postcondition: The square root of x has // been written to the standard output. ...

19. write_sqrt( -10 ); write_sqrt( 0 ); write_sqrt( 5.6 ); Example Which of these function calls meet the precondition ?

20. Always make sure the precondition is valid . . . • The programmer who calls the function is responsible for ensuring that the precondition is valid when the function is called.

21. . . . so the postcondition becomes true at the function’s end. • The programmer who writes the function counts on the precondition being valid, and ensures that the postcondition becomes true at the function’s end.

22. On the other hand, careful programmers also follow these rules: • When you write a function, you should make every effort to detect when a precondition has been violated. • If you detect that a precondition has been violated, then print an error message and halt the program... • ...rather than causing a disaster.

23. Example void write_sqrt( double x) // Precondition: x >= 0. // Postcondition: The square root of x has // been written to the standard output. { assert(x >= 0); ...

24. Advantages of Using Preconditions and Postconditions • Succinctly describes the behavior of a function... • ... without cluttering up your thinking with details of how the function works. • At a later point, you may reimplement the function in a new way ... • ... but programs (which only depend on the precondition/postcondition) will still work with no changes.