1. Slide 20.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process McGraw-Hill, 2004 Stephen R. Schach srs@vuse.vanderbilt.edu

2. Slide 20.2 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CHAPTER 20 TECHNICAL TOPICS

3. Slide 20.3 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter Overview l Source Code and Compiled Code l Modularity l Polymorphism and Dynamic Binding l Example of Polymorphism and Dynamic Binding l Maintenance Implications of Polymorphism and Dynamic Binding

4. Slide 20.4 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Source Code and Compiled Code l Programmers do not write all the code themselves –They invoke run-time routines as needed l A program exists in three forms –Source code –Compiled code –Executable load image

5. Slide 20.5 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Source Code and Compiled Code (contd) l Source code –Written in a language such as COBOL, C, C++, or Java l Source code has to undergo two transformations –It is compiled into compiled code (“object code”) –The compiled code is combined (linked) with the run-time routines it needs to form an executable load image

6. Slide 20.6 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Source Code and Compiled Code (contd) l Transformation of source code into an executable load image

7. Slide 20.7 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Source Code and Compiled Code (contd) l Monolithic information systems are inefficient –Changing a single line requires complete recompilation l Instead, a large information system should consist of a number of smaller code artifacts (or modules) –Now, only one model needs to be recompiled, followed by –The relinking of all the compiled code modules into an executable load image

8. Slide 20.8 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Source Code and Compiled Code (contd) l Recompiling one module, then relinking

9. Slide 20.9 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modularity l A large information system must be decomposed into modules –How is this decomposition to be performed? l Ensure that functionality coincides with module boundaries, that is, –All modules must have high cohesion –The methods (implementations of the operations) must be strongly related to one another, and weakly related to the methods of the other modules

10. Slide 20.10 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modularity (contd) l The traditional paradigm is: –Determine the client’s needs (requirements phase) –Draw up the specifications (analysis phase) –Design the information system as a set of modules with high cohesion (design phase) –Code the modules (implementation phase) l Cohesion is a fundamental principle of traditional design

11. Slide 20.11 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modularity (contd) l The design criterion of maximizing the cohesion of a module –Relates to solely to operations, and –Ignores data l This is the weakness of the traditional paradigm l What is needed is a paradigm that gives equal weight to data and operations –The object-oriented paradigm

12. Slide 20.12 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modularity (contd) l Cohesion was first put forward in 1976 l Best: Functional cohesion –A module has functional cohesion when it performs only one operation l Second best: Informational cohesion –A module has informational cohesion when it performs a number of related operations, all on the same data

13. Slide 20.13 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modularity (contd) l A class is a module with informational cohesion

14. Slide 20.14 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modularity (contd) l There are two possible ways multiple objects (instances of classes) could be implemented: –(a) Multiple instances of the attributes, multiple instances of the code for the methods –(b) Multiple instances of the attributes, a single instance of the code for each method l Approach (b) is automatically achieved by using an object-oriented programming language

15. Slide 20.15 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Modularity (contd) l (a) Incorrect and (b) correct implementation of objects

16. Slide 20.16 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Polymorphism and Dynamic Binding l The term polymorphism comes from two Greek words meaning “many shapes” l Example: Bank Card Class

17. Slide 20.17 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Polymorphism and Dynamic Binding (contd) l In a traditional information system, there have to be two different functions (methods), –print_monthly_statement_for_credit_card, and –print_monthly_statement_for_debit_card

18. Slide 20.18 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Polymorphism and Dynamic Binding (contd) l At run-time, each card is examined in turn –If it is a credit card, the monthly statement is printed by »Function print_monthly_statement_for_credit_card –If it is a debit card, the monthly statement is printed by »Function print_monthly_statement_for_debit_card

19. Slide 20.19 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Polymorphism and Dynamic Binding (contd) l In an object-oriented information system, choice of method is handled automatically

20. Slide 20.20 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Polymorphism and Dynamic Binding (contd) l In superclass Bank Card Class –declare an abstract (or virtual ) method printMonthlyStatement l In each of the subclasses –Implement a method for printing that type of monthly statement, also called printMonthlyStatement l When the monthly statements are being printed, the system –Automatically detects the card type, and –Invokes the appropriate version of printMonthlyStatement

21. Slide 20.21 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Polymorphism and Dynamic Binding (contd) l There are two different implementations of method printMonthlyStatement –Polymorphism l The relevant version of printMonthlyStatement is “bound” to the credit or debit card while the information system is running –Dynamic binding

22. Slide 20.22 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Polymorphism and Dynamic Binding (contd) l Polymorphism and dynamic binding make development easier l There is no need to write code to –Test whether an object is (say) a credit card or a debit card, and then –Invoke the appropriate function l Instead, the decision is made automatically by the object-oriented run-time system

23. Slide 20.23 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Example of Polymorphism and Dynamic Binding l While performing the design workflow, allocation of methods to classes is based on three factors –Responsibility-driven design –Inheritance –Polymorphism and dynamic binding

24. Slide 20.24 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Example of Polymorphism and Dynamic Binding l Example: MSG Foundation case study –Interaction diagrams include the messages: »Print list of mortgages, and »Print list of investments l Method printAsset must be able to print either an investment or a mortgage

25. Slide 20.25 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Example of Polymorphism and Dynamic Binding l Traditional paradigm –Two different functions are needed, namely »Function print_investment, and »Function print_mortgage l The information system must –First determine the type of the asset, then –Invoke the appropriate function

26. Slide 20.26 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Example of Polymorphism and Dynamic Binding l Object-oriented paradigm –Method printAsset utilizes polymorphism and dynamic binding

27. Slide 20.27 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Example of Polymorphism and Dynamic Binding l Version 1: Wrong allocation of method printAsset

28. Slide 20.28 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Polymorphism and Dynamic Binding Example l Version 1 uses inheritance instead of polymorphism –Method printAsset in class Asset Class is inherited unchanged by the two subclasses

29. Slide 20.29 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Example of Polymorphism and Dynamic Binding l Version 2: Correct allocation of method printAsset

30. Slide 20.30 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Example of Polymorphism and Dynamic Binding l Version 2 uses polymorphism and dynamic binding –Method printAsset in class Asset Class is abstract (or virtual) –There are two actual implementations of printAsset »One in class Investment Class, and »One in class Mortgage Class

31. Slide 20.31 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Example of Polymorphism and Dynamic Binding l When method printAsset is invoked –The object-oriented run-time system determines the class of the object that is invoking method printAsset –The object can be an instance of »Class Investment Class, or »Class Mortgage Class –The run-time system must go to the appropriate class, and –Execute the implementation of method printAsset found there

32. Slide 20.32 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance Implications of Polymorphism l Consider Version 2 again:

33. Slide 20.33 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance Implications of Polymorphism l Suppose the information system fails –The run-time system prints a message stating that the cause of the failure is “method printAsset ” l The maintainer cannot tell which was responsible: –The version of method printAsset in subclass Investment Class, or –The version of method printAsset in subclass Mortgage Class

34. Slide 20.34 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance Implications of Polymorphism l The strength of polymorphism and dynamic binding –The object-oriented run-time system automatically handles which version of printAsset is to be invoked –The potential ambiguity is automatically resolved l However, when something goes wrong at run-time –There is no way to tell which of the two identically named methods is the cause of the problem –The ambiguity cannot be resolved

35. Slide 20.35 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Maintenance Implications of Polymorphism l Polymorphism and dynamic binding are extremely powerful aspects of object-oriented technology that –Promote development, but –Can have a deleterious impact on maintenance