Chapter 11 Object-Oriented Design

1. Chapter 11 Object-Oriented Design

2. Objectives from book • To become familiar with the process of program development (§11.2). • To the relationship types: association, aggregation, composition, strong inheritance, and weak inheritance (§11.3). • To declare classes to represent the relationships among the classes (§11.3). • To design systems by identifying the classes and discovering the relationships among these classes (§11.4). • To implement the Rational class and process rational numbers using this class (§11.5). • To design classes that follow the class-design guidelines (§11.6). • To model dynamic behavior using sequence diagrams and statechart diagrams (§11.7 Optional) • To know the concept of framework-based programming using Java API (§11.8).

3. My Objectives • Object Oriented Modeling • Discuss real world experience • Network management System • PDA Products • Unit Testing

4. Software Development Process

5. Requirement Specification A formal process that seeks to understand the problem and document in detail what the software system needs to do. This phase involves close interaction between users and designers. Most of the examples in this book are simple, and their requirements are clearly stated. In the real world, however, problems are not well defined. You need to study a problem carefully to identify its requirements.

6. System Analysis Seeks to analyze the business process in terms of data flow, and to identify the system’s input and output. Part of the analysis entails modeling the system’s behavior. The model is intended to capture the essential elements of the system and to define services to the system.

7. System Design The process of designing the system’s components. This phase involves the use of many levels of abstraction to decompose the problem into manageable components, identify classes and interfaces, and establish relationships among the classes and interfaces.

8. Implementation The process of translating the system design into programs. Separate programs are written for each component and put to work together. This phase requires the use of a programming language like Java. The implementation involves coding, testing, and debugging.

9. Testing Ensures that the code meets the requirements specification and weeds out bugs. An independent team of software engineers not involved in the design and implementation of the project usually conducts such testing.

10. Deployment Deployment makes the project available for use. For a Java applet, this means installing it on a Web server; for a Java application, installing it on the client's computer.

11. Maintenance Maintenance is concerned with changing and improving the product. A software product must continue to perform and improve in a changing environment. This requires periodic upgrades of the product to fix newly discovered bugs and incorporate changes.

12. Software Methodologies • Waterfall Model • Evolutionary Model • Incremental Model • Agile Methodology

13. Waterfall Model • Top-down • Development steps are executed sequentially • Gate approvals between consecutive steps • Documentation oriented • Advantages: • simple for management • Disadvantage: • Documents are costly to produce and approve. • Some steps would get frozen prematurely • Not developing what the customer wants • Being inflexible to change.

14. Evolutionary Model • Performs all processes in at least 2 passes • First pass implements only those requirements that are firm or known. • Negotiates with the customer after the completion of a pass before the next pass begins. • Advantage: • Developing requirements incrementally • meeting the customer’s immediate needs. • Disadvantage • resulting system architecture is often corrupted.

15. Incremental Model • customers identify the system features and prioritize them. • Development prioritizes delivery increments. • Each successive delivery includes an enlarging subset of the feature list. • Requirements of the first increment are frozen, development proceeds in detail on the increment. • Concurrently consider requirement changes for the next increment • Advantage: • Enables faster delivery to the customer who in turn gains experience on the system and provide feedback for later increments. • Lower risk of overall project failure • . top priority features are delivered first - tested more thoroughly by the development organization as well as in operation.

16. Agile • Principles: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan • Goals: • Accept customer changes any time; • have short daily communications between customers and developers, • develop and deliver small increments in lieu of one release as at the end of the waterfall model. • Advocates putting top developers in a bullpen and let the team self organize. • Problem: Documentation is definitely downplayed. Small Projects (< 10 )

17. Observations • Waterfall model is a conceptual model • Personally have worked on combination of waterfall, incremental, and evolutionary • Maintenance is 80% of the life cycle cost • Problems? • Documentation • Institutional knowledge • Software industry often reinvents the wheel

18. Some challenges on Software Architecture • Network Management System • PDA

19. WS WS Wide Area Network EMS NMS EMS NE NE NE NE XC NE XC NE NE Optical network and Network Management

20. Network Management System Example • An optical communication network using SDH • Network management system another network using TMN • Diverse nodes with common functions and differing in hardware, functionalities, and capacities • Developed by globally distributed teams • Development of releases transitioned successfully from one team to another • Two key factors are product line architecture; incremental and iterative development

21. Product Architecture to Product Line Architecture • Each delivery is custom-tailored • Paradigm shift: Product Development House to Product Line Platform to generate similar products with custom options. • Benefits – reuse

22. Software Architecture – Logical View • Database for • Configuration Management – on individual network configuration • Account management – for end customers • Superclass and subclasses • NE common properties • NE specific properties • New NE’s just inherit the common properties and override those that are specific

23. Applications • PDA: From calendar, address book, calculator, notes, spreadsheet • To • exchange business cards • internet • email • instant messaging • on-line search • VoIP • GPS • camera etc.

24. Relationships among Classes • Association • Aggregation • Composition • Inheritance

25. Other Applications • n-tier architectures: GUI, server, and DB

26. Back to OOM • OOM concepts

27. Association Association represents a general binary relationship that describes an activity between two classes. An association is usually represented as a data field in the class.

28. Translation is not Unique NOTE: If you don’t need to know the courses a student takes or a faculty teaches, the data field courseList in Student or Faculty can be omitted.

29. Association Between Same Class Association may exist between objects of the same class. For example, a person may have a supervisor.

30. Aggregation and Composition Aggregation is a special form of association, which represents an ownership relationship between two classes. Aggregation models the has-a relationship. If an object is exclusively owned by an aggregated object, the relationship between the object and its aggregated object is referred to as composition.

31. Representing Aggregation in Classes An aggregation relationship is usually represented as a data field in the aggregated class.

32. Inner Classes Translation If Name or Address is used in the Person class only, they can be declared as an inner class in Person. For example, public class Person { private Name name; private Address address; ... class Name { ... } class Address { ... } }

33. Inheritance Inheritance models the is-an-extension-of relationship between two classes.

34. Weak Inheritance Relationship A weak is-an-extension-of relationship can be represented using interfaces. For example, the weak is-an-extension-of relationship “students are comparable based on their grades” can be represented by implementing the Comparable interface, as follows:

35. Class Design 1. Identify classes for the system. 2. Describe attributes and methods in each class. 3. Establish relationships among classes. 4. Create classes.

36. Example 11.1 Borrowing Loans Name Loan Person Borrower Address

37. Example 11.1 Borrowing Loans, cont. The following is a test program that uses the classes Name, Person, Address, Borrower, and Loan. Run BorrowLoan

38. Example 11.2 The Rational Class Rational TestRationalClass Run

39. Class Design Guidelines • Designing a Single Class. • Using Modifiers public, protected, private and static • Using Inheritance or Aggregation • Using Interfaces or Abstract Classes

40. Designing a Class • A class should describe a single entity or a set of similar operations. • Break a single entity with too many responsibilities into several classes to separate responsibilities. • Example: The String class, StringBuffer class, and StringTokenizer class all deal with strings, but have different responsibilities.

41. Designing a Class, cont. • Classes are usually designed for use by a wide range of applications • Provide a variety of ways for customization through properties and methods.

42. Designing a Class, cont. • Classes are designed for reuse. • Users can incorporate classes in many different combinations, orders, and environments. • Hence design a class that • DON’T: imposes restrictions on what or when the user can do with it, • DO: ensure that properties can be set in any order, with any combination of values, and methods function independently of their order of occurrence.

43. Designing a Class, cont. • Provide a public no-arg constructor • Override the equals method and the toString method defined in the Object class whenever possible.

44. Designing a Class, cont. • Follow standard Java programming style and naming conventions. • Choose informative names for classes, data fields, and methods. • Always place the data declaration before the constructor, • and place constructors before methods. • Always provide a constructor and initialize variables to avoid programming errors.

45. Using Visibility Modifiers • Each class can present two contracts: • one for the users of the class • one for the extenders of the class. • Make fields private and accessor methods public if they are intended for the users of the class. • Make the fields or method protected if they are intended for extenders of the class. • The contract for the extenders encompasses the contract for the users. • The extended class may increase the visibility of an instance method from protected to public, or change its implementation, but you should never change the implementation in a way that violates that contract.

46. Using Visibility Modifiers, cont. • Use the private modifier to hide its data from direct access by clients. • Use get methods and set methods to provide users with access to the private data, but only to private data you want the user to see or to modify. • Hide methods not intended for client use. • Example 11.2: gcd method in the Rational class is private because it is only for internal use within the class.

47. Using the static Modifier • A property that is shared by all the instances of the class should be declared as a static property.

48. Using Inheritance or Aggregation? inheritance versus aggregation = is-an-extension-of relationship versus has-a relationship. Example: an apple is fruit; so use inheritance to model the relationship between the classes Apple and Fruit. Example: A person has a name; so use aggregation to model the relationship between the classes Person and Name.

49. Using Inheritance or Aggregation? cont. The choice between inheritance and aggregation is not always obvious. Example: we used inheritance to model the relationship between the classes Circle and Cylinder. But … if you argue that a cylinder consists of circles; thus, you might use aggregation to define the Cylinder class as follows:

50. Using Inheritance or Composition, cont. public class Cylinder { private Circle circle; /** Constructors */ /** Methods */ }