1. Introduction to Software Design Chapter 1

2. Chapter 1: Introduction to Software Design2 Chapter Objectives Intro - Software OOP Inheritance, interfaces, abstract classes, overloading, overriding, etc. Use data abstraction, procedural abstraction, and information hiding to manage complexity

3. Chapter 1: Introduction to Software Design3 The Software Challenge In industry, a software product is expected to be used for an extended period of time by a moron Initial specification for a software product may be incomplete Specification is clarified through extensive interaction between users (maybe) of the software and the system analyst A requirements specification should be generated at the beginning of any software project Designers and users should both approve the document

4. Chapter 1: Introduction to Software Design4 Software Life Cycle Models Waterfall model: simplest way of organizing activities that transforms software from one stage to another Activities are performed in sequence and the results of one flows into the next Waterfall model is simple but unworkable Fundamental flaw is assumption that each stage can and must be completed before the next one occurs Sometimes, it is not until the product is finished that the user can fully express his or her requirements

5. Chapter 1: Introduction to Software Design5 Waterfall Model (continued)

6. Chapter 1: Introduction to Software Design6 Waterfall Model (continued)

7. Chapter 1: Introduction to Software Design7 Software Life Cycle Activities (continued) Requirements Specification System analyst works with software users to clarify the detailed system requirements Questions include format of input data, desired form of any output screens, and data validation Analysis Make sure you completely understand the problem before starting the design or program a solution Evaluate different approaches to the design

8. Chapter 1: Introduction to Software Design8 Software Life Cycle Activities (continued) Design Top-down approach: breaking a system into a set of smaller subsystems Object-oriented approach: identification of a set of objects and specification of their interactions UML diagrams are a design tool to illustrate the interactions between Classes Classes and external entities

9. Chapter 1: Introduction to Software Design9 Key Programming and Design Issues Modularity Modularity Modifiability Modifiability Ease of use Ease of use Fail-safe programming Fail-safe programming Efficiency Efficiency Generality and Reusability Generality and Reusability

10. Chapter 1: Introduction to Software Design10 Achieving a Modular Design: Abstraction Abstraction data – focuses on what operations do data – focuses on what operations do procedural – separates the purpose of a method from the implementation procedural – separates the purpose of a method from the implementation abstract data type (ADT) – a collection of data and a set of operations abstract data type (ADT) – a collection of data and a set of operations Information hiding – limits the ways that data and methods can be accessed Information hiding – limits the ways that data and methods can be accessed Object Oriented Programming Object Oriented Programming Encapsulation Encapsulation Inheritance Inheritance Polymorphism Polymorphism Top-Down design Top-Down design Focuses on the verbs (actions that are to be performed) Focuses on the verbs (actions that are to be performed) Identifies the things that need to be done, subdivides tasks, etc. Identifies the things that need to be done, subdivides tasks, etc.

11. Chapter 1: Introduction to Software Design11 Common Design Flaws - OOP Classes that make direct modification to other classes. Classes that make direct modification to other classes. Weak within class cohesiveness, strong between class cohesiveness. Weak within class cohesiveness, strong between class cohesiveness. Classes with too much responsibility. Classes with too much responsibility. Classes with no responsibility. Classes with no responsibility. Classes with unused responsibility. Classes with unused responsibility. Misleading Names. Misleading Names. Unconnected Responsibility. Unconnected Responsibility. Innapropriate use of inheritance. Relationship is not is-a, or class cannot inherit any useful behavior from super class. Innapropriate use of inheritance. Relationship is not is-a, or class cannot inherit any useful behavior from super class. Repeated functionality. Repeated functionality.

12. Chapter 1: Introduction to Software Design12 Another key programming issue - Style Proper use of white space Proper use of white space Indentation of code blocks Indentation of code blocks Blank lines Blank lines Well-chosen identifiers Well-chosen identifiers Class names – each word capitalized Class names – each word capitalized Method names – first letter lower case, each word capitalized Method names – first letter lower case, each word capitalized Named constants – all upper case, underscores separate words Named constants – all upper case, underscores separate words Method variables – all lower case Method variables – all lower case Object/class variables – append an underscore after the name Object/class variables – append an underscore after the name Documentation Documentation see next page see next page

13. Chapter 1: Introduction to Software Design13 Documentation What is a comment? What is a comment? What should a comment say? What should a comment say? Where do you need comments (for this class)? Where do you need comments (for this class)? every public/protected method. every public/protected method. @param @param @return @return @precondition @precondition @postcondition @postcondition every class every class every class member every class member

14. Chapter 1: Introduction to Software Design14 A comment is text that is added to program code that is ignored by the compiler /* a multi-line comment */ /** Javadoc */ // single line comment See http://java.sun.com/j2se/javadoc/writingdoccomments/ http://www.time2help.com/doc/online_help/idh_java_doc_tag_support.htm A comment should describe What a program segment should do The circumstances under which it will do it You should have an opening comment for each class method

15. Chapter 1: Introduction to Software Design15 What’s a good comment? What’s a bad comment? What’s a neutral comment?

16. Chapter 1: Introduction to Software Design16 A good comment brings clarity public class Ratio { /* an object for storing a fraction like 2/3 */ A neutral comment is one doesn’t really help or hinder protected int numerator; // numerator of ratio A bad comment is one that is misleading public class Ratio { /* this class does whatever you want */

17. Chapter 1: Introduction to Software Design17 When do you write comments? Comments should be created ASAP Comments should not be added after the fact! However, we all do this Note: if you name your stuff (variables and methods) appropriately, you generally don’t need as many comments

18. Chapter 1: Introduction to Software Design18 Using Abstraction to Manage Complexity An abstraction is a model of a physical entity or activity Abstraction helps programmers deal with complex issues in a piecemeal fashion Procedural abstraction: distinguish what is to be achieved by a procedure from its implementation Data abstraction: specify the data objects for a problem and the operations to be performed on them without concern for their representation in memory

19. Chapter 1: Introduction to Software Design19 Using Abstraction to Manage Complexity (continued) If a higher-level class references a data object only through its methods, the higher-level class will not have to be rewritten, even if the data representation changes Information hiding: Concealing the details of a class implementation from users of the class

20. Chapter 1: Introduction to Software Design20 Abstract Data Types, Interfaces, and Pre- and Postconditions A major goal of software engineering is to write reusable code Abstract data type (ADT): The combination of data together with its methods A Java interface is a way to specify an ADT The interface specifies the names, parameters, and return values of the ADT methods without specifying how the methods perform their operations and without specifying how the data is internally represented Each class that implements an interface must provide the definitions of all methods declared in the interface

21. Chapter 1: Introduction to Software Design21 Abstract Data Types, Interfaces, and Pre- and Postconditions (continued)

22. Chapter 1: Introduction to Software Design22 Abstract Data Types, Interfaces, and Pre- and Postconditions (continued) You cannot instantiate an interface You can declare a variable that has an interface type and use it to reference an actual object A Java interface is a contract between the interface designer and the programmer who codes a class that implements the interface Precondition: a statement of any assumptions or constraints on the method data before the method begins execution Postcondition: a statement that describes the result of executing a method

23. Chapter 1: Introduction to Software Design23 Introduction to Inheritance and Class Hierarchies Popularity of OOP is that it enables programmers to reuse previously written code saved as classes (extensible, encapsulation, polymorphism) All Java classes are arranged in a hierarchy, starting with Object, which is the superclass of all Java classes Inheritance and hierarchical organization allow you to capture the idea that one thing may be a refinement or extension of another

24. Chapter 1: Introduction to Software Design24

25. Chapter 1: Introduction to Software Design25 Is-a Versus Has-a Relationships One misuse of inheritance is confusing the has-a relationship with the is-a relationship The has-a relationship means that one class has the second class as an attribute We can combine is-a and has-a relationships The keyword extends specifies that one class is a subclass of another

26. Chapter 1: Introduction to Software Design26 A Superclass and a Subclass Consider two classes: Computer and Laptop A laptop is a kind of computer and is therefore a subclass of computer

27. Chapter 1: Introduction to Software Design27 Initializing Data Fields in a Subclass and the No-Parameter Constructor Private data fields belonging to a base class must be initialized by invoking the base class’s constructor with the appropriate parameters If the execution of any constructor in a subclass does not invoke a superclass constructor, Java automatically invokes the no-parameter constructor for the superclass Initializes that part of the object inherited from the superclass before the subclass starts to initialize its part of the object

28. Chapter 1: Introduction to Software Design28 Protected Visibility for Superclass Data Fields Private data fields are not accessible to derived classes Protected visibility allows data fields to be accessed either by the class defining it or any subclass In general, it is better to use private visibility because subclasses may be written by different programmers and it is always good practice to restrict and control access to the superclass data fields

29. Chapter 1: Introduction to Software Design29 Method Overriding If a derived class has a method found within its base class, that method will override the base class’s method The keyword super can be used to gain access to superclass methods overridden by the base class A subclass method must have the same return type as the corresponding superclass method

30. Chapter 1: Introduction to Software Design30 Method Overloading Method overloading: having multiple methods with the same name but different signatures in a class Constructors are often overloaded Example: MyClass(int inputA, int inputB) MyClass(int inputA, int inputB, double inputC)

31. Chapter 1: Introduction to Software Design31 Polymorphism A variable of a superclass type can reference an object of a subclass type Polymorphism means many forms or many shapes Polymorphism allows the JVM to determine which method to invoke at run time At compile time, the Java compiler can’t determine what type of object a superclass may reference but it is known at run time

32. Chapter 1: Introduction to Software Design32 Abstract Classes, Assignment, and Casting in a Hierarchy An interface can declare methods but does not provide an implementation of those methods Methods declared in an interface are called abstract methods An abstract class can have abstract methods, data fields, and concrete methods Abstract class differs from a concrete class in that An abstract class cannot be instantiated An abstract class can declare abstract methods, which must be implemented in its subclasses

33. Chapter 1: Introduction to Software Design33 Abstract Classes and Interfaces Like an interface, an abstract class can’t be instantiated An abstract class can have constructors to initialize its data fields when a new subclass is created Subclass uses super(…) to call the constructor May implement an interface but it doesn’t have to define all of the methods declared in the interface Implementation is left to its subclasses

34. Chapter 1: Introduction to Software Design34 Summary of Features of Actual Classes, Abstract Classes, and Interfaces

35. Chapter 1: Introduction to Software Design35 Using Multiple Interfaces to Emulate Multiple Inheritance If we define two interfaces, a class can implement both Multiple interfaces emulate multiple inheritance

36. Chapter 1: Introduction to Software Design36 Run-time Errors or Exceptions Run-time errors Occur during program execution Occur when the JVM detects an operation that it knows to be incorrect Cause the JVM to throw an exception Examples of run-time errors include Division by zero Array index out of bounds Number format and Input mismatch error Null pointer exceptions

37. Chapter 1: Introduction to Software Design37 Run-time Errors or Exceptions (continued)

38. Chapter 1: Introduction to Software Design38 Logic Errors A logic error occurs when the programmer or analyst Made a mistake in the design of a class or method Implemented an algorithm incorrectly Most logic errors do not cause syntax or run-time errors and are thus difficult to find Sometimes found through testing Sometimes found during real-world operation of the program

39. Chapter 1: Introduction to Software Design39 The Exception Class Hierarchy When an exception is thrown, one of the Java exception classes is instantiated Exceptions are defined within a class hierarchy that has the class Throwable as its superclass Classes Error and Exception are subclasses of Throwable RuntimeException is a subclass of Exception

40. Chapter 1: Introduction to Software Design40 The Class Throwable Throwable is the superclass of all exceptions All exception classes inherit the methods of throwable

41. Chapter 1: Introduction to Software Design41 The Class Throwable (continued)

42. Chapter 1: Introduction to Software Design42 Checked and Unchecked Exceptions Two categories of exceptions: checked and unchecked Checked exception normally not due to programmer error and is beyond the control of the programmer Unchecked exception may result from Programmer error Serious external conditions that are unrecoverable

43. Chapter 1: Introduction to Software Design43 Checked and Unchecked Exceptions

44. Chapter 1: Introduction to Software Design44 Catching and Handling Exceptions When an exception is thrown, the normal sequence of execution is interrupted Default behavior Program stops JVM displays an error message The programmer may override the default behavior by Enclosing statements in a try block Processing the exception in a catch block

45. Chapter 1: Introduction to Software Design45 Uncaught Exceptions When an exception occurs that is not caught, the program stops and the JVM displays an error message and a stack trace The stack trace shows the sequence of method calls, starting at the method that threw the exception and ending at main

46. Chapter 1: Introduction to Software Design46 The try-catch-finally Sequence Avoid uncaught exceptions Write a try-catch sequence to catch an exception Handle it rather than relying on the JVM Catch block is skipped if all statements within the try block execute without error

47. Chapter 1: Introduction to Software Design47 Handling Exceptions to Recover from Errors Exceptions provide the opportunity to Recover from errors Report errors User error is a common source of error and should be recoverable Catch block within the first catch clause having an appropriate exception class executes, others are skipped Compiler displays an error message if it encounters an unreachable catch clause

48. Chapter 1: Introduction to Software Design48 The finally Block When an exception is thrown, the flow of execution is suspended and there is no return to the try block There are situations in which allowing a program to continue after an exception could cause problems The code in the finally block is executed either after the try block is exited or after a catch clause is exited The finally block is optional

49. Chapter 1: Introduction to Software Design49 Throwing Exceptions Instead of catching an exception in a lower-level method, it can be caught and handled by a higher-level method Declare that the lower-level method may throw a checked exception by adding a throws clause to the method header Can throw the exception in the lower-level method, using a throw statement The throws clause is useful if a higher-level module already contains a catch clause for this exception type

50. Chapter 1: Introduction to Software Design50 Throwing Exceptions (continued) Can use a throw statement in a lower-level method to indicate that an error condition has been detected Once the throw statement executes, the lower-level method stops executing immediately

51. Chapter 1: Introduction to Software Design51 Catching Exceptions Example