1. Topic 9Summer 2003 1 ICS 52: Introduction to Software Engineering Lecture Notes for Summer Quarter, 2003 Michele Rousseau Topic 9 Partially based on lecture notes written by Sommerville, Frost, & Easterbrook. Duplication of course material for any commercial purpose without the written permission of the lecturers is prohibited

2. Topic 9Summer 2003 2 Today’s Lecture l A brief introduction to Classes & Objects

3. Topic 9Summer 2003 3 Noun extraction for design Complements design by information hiding

4. Topic 9Summer 2003 4 Remember this? Invoice Processing System – Object Model This system can: Issue invoices to customers Receive payments Issue receipts for payments Issue reminders for unpaid invoices The dashed line means that one object uses the attributes or services of another object

5. Topic 9Summer 2003 5 Choosing classes & objects l At the conceptual level: an object is a set of responsibilities, including responsibility for itself (encapsulates functions and data) l At the specification level: an object is a set of methods (its interface), which can be invoked by itself or other objects l At the implementation level: an object is code (methods) and data (attributes) Object Oriented approach attempts to manage complexity in real-world problems

6. Topic 9Summer 2003 6 Objects l Have Public and Private sides l OOD –views the world as a system of cooperating collaboration agents.

7. Topic 9Summer 2003 7 Some Terminology l Encapsulation – bundling operations and data that are conceptually linked (like putting them in a capsule) l Information Hiding – Making the capsule opaque l Method – an action l Attribute – a variable/constant l Object – primitive programming element l Class – a generic specification for an arbitrary number of similar objects – (abstract, template)

8. Topic 9Summer 2003 8 An OOD Process l Find the classes in your system l Determine operations for each class l Determine how objects will need to collaborate with each other

9. Topic 9Summer 2003 9 Hints for Choosing Classes l How do I find classes, attributes and so on? Look at the requirements »classes often correspond to nouns »attributes often correspond to abstract nouns »operations often correspond to verbs

10. Topic 9Summer 2003 10 Determining Classes l Model physical objects (employees, invoices, printers, etc..) l If more than 1 word is used for the same concept choose the one that is most meaningful. l Be wary of adjectives – does it describe new behavior? l Model known interfaces l Model the values of attributes – but don’t model attributes e.g. Line and length – class or attribute

11. Topic 9Summer 2003 11 A class should... l represent a coherent concept Principle: Low Coupling, High Cohesion l have a small, well-defined set of responsibilities l be named with a singular noun that says what each each instance of the class is l have no more than 10-20 operations

12. Topic 9Summer 2003 12 An Example FastData Inc. wants a subsystem to process office supply orders via the Web. The user will supply via a form their name, password, account number, and a list of supplies along with an indication of the quantities desired. The subsystem will validate the input, enter the order into a database, and generate a receipt with the order number, expected ship date, and the total cost of the order. If the validation step fails, the subsystem will generate an error message describing the cause of the failure

13. Topic 9Summer 2003 13 You may need to rewrite Make it concise. l “FastData, Inc. employees may order office supplies via the Internal Web and receive a receipt confirming the order. The order must include the user name, user password, account number, and the list of supplies. A receipt must be generated containing an order number, ship date, and total cost. If the order is valid, it must be entered into an order database. If the order is invalid, an error message must be generated.”

14. Topic 9Summer 2003 14 Formalize the Strategy l Identify the nouns of the description, which serve as the basis for identifying the subsystem’s classes. l Look for out-of-domain nouns (and throw them out!) l Look for abstract nouns (use these for attributes) l The remaining nouns are good candidates for classes!

15. Topic 9Summer 2003 15 Find the nouns l “FastData, Inc. employees may order office supplies via the Internal Web and receive a receipt confirming the order. The order must include the user name, user password, account number, and the list of supplies. A receipt must be generated containing an order number, ship date, and total cost. If the order is valid, it must be entered into an order database. If the order is invalid, an error message must be generated.”

16. Topic 9Summer 2003 16 Nouns –Employees –Office Supplies  Item –Internal Web –Receipt –Order –User name –User password – Account number – Order number – Ship date – Total cost – Order database – Error message – List of supplies

17. Topic 9Summer 2003 17 Nouns l Out-of-Domain Internal Web l Abstract user name user password account number order number ship date total cost list of supplies l Good Candidates employee item (was office supplies) receipt order order database error message l Notes We have decided not to worry about the Web in this design. Instead we focus on the inputs and outputs and defer the Web details until later.

18. Topic 9Summer 2003 18 Basic Classes Employee Name Password Account # Order Number Employee Item Error Message Item Order Ship Date Total cost Receipt Order Order Database l This gives us a starting place to refine and revise

19. Topic 9Summer 2003 19 Assigning Responsibilities l Responsibilities include 2 key items The knowledge an object maintains The actions an object can perform l An object is a client when it requests services from another object. l An object is a server when it fulfills a request from another object. l Where to look – Requirements Classes

20. Topic 9Summer 2003 20 Identifying Responsibilities l Look for the verbs Which ones clearly represent actions that some object must perform Note where information is mentioned »Information an object must maintain and manipulate l Look at they system as a whole (walkthrough) l Look at the classes

21. Topic 9Summer 2003 21 Assigning Responsibilities l Try to evenly distribute system intelligence l State responsibilities as generally as possible l Keep behavior with related information l Keep information about 1 thing in 1 place l Share responsibilities among related objects

22. Topic 9Summer 2003 22 What Operations go with which Class? Employee Name Password Account # Order Number Employee Item SendReceipt() SendErrorMsg() AddItem() Error Message Item Order Ship Date Total cost Receipt Order Order Database

23. Topic 9Summer 2003 23 Final Notes l Refine, Revise l Define relationships

24. Topic 9Summer 2003 24 Design Recap

25. Topic 9Summer 2003 25 Important concepts l Architectural styles l Information hiding l Noun extraction l Uses diagram l Comprises diagram

26. Topic 9Summer 2003 26 How do we decide if a design is the best possible design? l Ability to predict comes with experience l Qualities to look for: Verifiability, Maintainability, Repairability, Evolvability, Reusability, Portability, Understandability, Interoperability l Principles to maintain: Rigor & formality, Separation of concerns, Modularity, Abstraction, Anticipation of change, Generality

27. Topic 9Summer 2003 27 What is a Good Class? l …and what should not be a class? l A class should be named with a noun Example: “class Book” l A class should not represent a task or operation Don’t do this: “class FindABook” Don’t have classes described as “performing” something l A class should contain several related operations These correspond to the class’ responsibilities l A class should contain at least one attribute l A class should represent a single abstraction

28. Topic 9Summer 2003 28 Is fan-in, fan-out relevant? l Yes, but it’s not as important as other indications of a good design l High cohesion and low coupling are the most important l For smaller systems, the uses diagram is the next most important l For larger systems, the comprises diagram is also important

29. Topic 9Summer 2003 29 How does high level architecture affect module interaction? l Architectural styles restrict the way in which components can be connected Prescribe patterns of interaction Promote fundamental principles »Rigor, Separation of concerns, Modularity, Abstraction, Anticipation of change, Generality, Incrementality »Low coupling, High cohesion

30. Topic 9Summer 2003 30 Do we have to code up the modules? l Yes, but later.

31. Topic 9Summer 2003 31 Why do we define levels in the uses diagram? l The process of doing so helps identify cycles (which are usually bad) l The levels are used in making an integration test plan

32. Topic 9Summer 2003 32 How many levels should we have in a uses diagram? l It depends. l Small systems may only have 2 or 3 l Larger systems may have many more, or they may remain fairly “shallow”

33. Topic 9Summer 2003 33 Acceptance testing? l Acceptance testing is performed after implementation and integration testing is complete, before the product is given to the client l Acceptance test plans are made during the requirements phase l The acceptance test plan includes a high-level description of what is being tested, and specific test inputs, along with expected outputs.

34. Topic 9Summer 2003 34 Integration testing? l Integration testing is performed after implementation and module testing, before acceptance testing l The integration test plan is made during design l The integration test plan includes a plan of the order of integration and specific test cases.

35. Topic 9Summer 2003 35 Integration Testing

36. Topic 9Summer 2003 36 V-Model of Development and Testing Develop Acceptance Tests Acceptance Test ReviewRequirements Review Develop RequirementsExecute System TestsDevelop Integration Tests Integration Tests ReviewDesign Review DesignExecute Integration TestsDevelop Unit Tests Unit Tests ReviewCode Review CodeExecute Unit Tests

37. Topic 9Summer 2003 37 Integration Test Plans l Goal (Why?) Ensure modules make compatible assumptions about each other. Exercise interfaces between modules, as opposed to functionality within modules l Hard part: Identifying interactions that reveal agreement or disagreement on assumptions l Approach (How?) Combine more and more modules Use USES hierarchy »Work up from lowest numbers  Use test harnesses to test each group of modules »Work down from highest numbers  Use stubs as mockups to test each group of modules l Test execution can be done during implementation effort

38. Topic 9Summer 2003 38 Integration Test Example Provided Interface Main component Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface

39. Topic 9Summer 2003 39 Integration Testing Tools l Extra code you write for integration testing. Needed because not all modules are ready at the same time. l Harnesses or drivers Call or invoke modules and pass parameters to them l Stubs Are called by modules, do minimal processing, return reasonable values

40. Topic 9Summer 2003 40 Test Harnesses (bottom-up integration) Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Test Harness Required Interface Provided Interface Test Harness Required Interface

41. Topic 9Summer 2003 41 Stubs (top-down integration) Provided Interface Main component Required Interface Provided Interface Stub Required Interface Provided Interface Stub Required Interface Provided Interface Stub Required Interface

42. Topic 9Summer 2003 42 Stubs Provided Interface Main component Required Interface Provided Interface Stub Required Interface Provided Interface Stub Required Interface Provided Interface Subcomponent Required Interface Provided Interface Stub Required Interface Provided Interface Stub Required Interface

43. Topic 9Summer 2003 43 Stubs Provided Interface Main component Required Interface Provided Interface Subcomponent Required Interface Provided Interface Stub Required Interface Provided Interface Subcomponent Required Interface Provided Interface Stub Required Interface Provided Interface Stub Required Interface

44. Topic 9Summer 2003 44 Integration Testing Strategies l Integrate and test increasingly larger subsets of modules l Top-down integration testing Can be done before units are fully coded Requires stubs l Bottom-up integration testing Requires test harnesses or drivers Can thoroughly test lower modules but postpones detection of major integration problems l Hybrid of both most common in practice