Software LEIC/LETI. Lecture 10

Transcription

1 Software LEIC/LETI Lecture 10

2 Last Lecture Software Design Design as Structure Data source architectural patterns FénixFramework

3 Today Software Design Design as Structure Design Principles Design as Process

4 Design as Structure

5 What are the qualities of a good design?

6 High Cohesion single responsibility within a module

7 High Cohesion single responsibility within a module increases locality of change

8

9 contains both domain logic and database access

10 Low Coupling reduces dependencies between modules

11 Low Coupling reduces dependencies between modules reduces change propagation

12

13 interface does not completely hide the database structure

14 Design Principles (

15 Open Close Principle Modules should be open for extension but closed for modifications

16 Open Close Principle Modules should be open for extension but closed for modifications low coupling from clients hierarchy high cohesion

17 Bank 1 * Account int gettotalamount() void deposit(int amount) void withdraw(int amount) SalaryAccount void deposit(int amount) void withdraw(int amount) Withdrawal Account void deposit(int amount) void withdraw(int amount)

18 Dependency Inversion Principle High-level modules should not depend on low-level modules. Both should depend on abstractions Abstractions should not depend on details. Details should depend on abstractions.

19 Dependency Inversion Principle High-level modules should not depend on low-level modules. Both should depend on abstractions Abstractions should not depend on details. Details low coupling by depending on abstractions should depend on abstractions.

20

21 Interface Segregation Principle Clients should not be forced to depend upon interfaces that they don't use

22 Interface Segregation Principle Clients should not be forced to depend upon interfaces that they don't use low coupling by depending on minimal responsibilities

23

24

25 Single Responsibility Principle A module should have only one reason to change

26 Single Responsibility Principle A module should have only one reason to change high cohesion

27

28 Liskov's Substitution Principle Derived types must be completely substitutable for their base types

29 Liskov's Substitution Principle Derived types must be completely substitutable for their base types low coupling because the extensions preserve the abstraction

30

31

32 Project

33 Interface to define low coupling between broker and hotel module RoomBookingData, HotelException and Room.Type

34 Interfaces and Abstractions

35 Interfaces hide an implementation low coupling

36 Interfaces hide an implementation low coupling encapsulation

37 Types of Interfaces

38 Exposes attributes

39 Exposes attributes no encapsulation

40 Contains complex entities as parameters

41 Contains complex entities as parameters shared data model

42 Only contains simple data types

43 Only contains simple data types no shared data model

44 Is programming language independent

45 Is programming language independent WSDL

46 Contains the meta-model

47 Contains the meta-model XML Schema

48 Is it easy to define an interface? one which provides low coupling

49 (

50 (

51 A good interface depends on a good abstraction

52 What is the abstraction of animal?

53 What is the abstraction of animal? body and members

54

55 animal for a zoo

56 animal for a zoo animal for a butcher shop

57 animal for a zoo animal for a butcher shop a pet for a kid

58 animal for a zoo animal for a butcher shop a pet for a kid I lost my pet

59 Abstractions depend on the context!

60 It is not easy to find the right abstractions it can take a long time

61 How to identify the abstractions?

62 Design as Process

63 Top-down and Bottom-up

64 Top-down and from requirements to design structure Bottom-up

65 Top-down and from requirements to design structure Bottom-up refactoring of implemented functionality

66 Top-down approach to design from the problem space to the solution space

67

68 System context and interaction

69 System context and interaction Architectural design

70 System context and interaction Architectural design Object class classification

71 System context and interaction Architectural design Object class classification Design models

72 System context and interaction Architectural design Object class classification Design models Interface specification

73 Weather station

74 System Context and Interactions (Sommerville, figure 7.1)

75 System Context and Interactions (Sommerville, figure 7.2)

76 System Context and Interactions (Sommerville, figure 7.3)

77 Architecture design (Sommerville, figure 7.4)

78 Architecture design (Sommerville, figure 7.5)

79 Object identification (Sommerville, figure 7.6)

80 Object identification inferred from the use cases (Sommerville, figure 7.6)

81 Object identification (Sommerville, figure 7.6) inferred from the use cases domain entities

82 Design models (Sommerville, figure 7.7)

83 Design models (Sommerville, figure 7.7) the blueprints for programmers

84 Design models (Sommerville, figure 7.8)

85 Design models (Sommerville, figure 7.8) the blueprints for programmers

86 Interface specification (Sommerville, figure 7.9)

87 Interface specification (Sommerville, figure 7.9) programmers can work in parallel

88 Bottom-up approach to design refactor functionalities

89 How do statically typed object-oriented languages expect programs to evolve?

90 First, abstract classes, then concrete classes, then objects,

91 But abstractions depend on the context concrete cases first, abstractions after

92 How top-down approaches define abstractions?

93 How top-down approaches define abstractions? analyze several cases, use cases

94 Can we build abstractions from code cases?

95 Can we build abstractions from code cases? refactoring

96 We move from a small set of code cases to abstractions

97 But, which abstraction?

98 The abstraction that fits the already implemented cases

99 The abstraction that fits the already implemented cases consider the known cases

100 Evolve the abstraction as more cases need to be considered

101 Evolve the abstraction as more cases need to be considered evolution of abstractions

102 It is necessary to keep the code running

103 It is necessary to keep the code running regressive testing

104 What is the refactoring process?

105 Add functionality!

106 Test!

107 Change Structure!

108 Test!

109 Repeat!

110 Refactoring: a small example (

111 Introduce null object refactoring

112 Introduce null object refactoring

113 if (customer == null) plan = BillingPan.basic(); else plan = customer.getplan();

114 What would we like to have?

115 plan = customer.getplan();

116 How can we get it?

117

118 Which steps?

119 class Site... Customer getcustomer() { return customer; } Customer customer; class Customer... public BillingPan getplan() {...} public String getname() {...} public PaymentHistory gethistory() {...} BillingPlan plan; if (customer == null) plan = BillingPlan.basic(); else plan = customer.getplan();...

120 class Customer... public boolean isnull() { return false; } protected Customer() {} // clients do need to not know about null class } static Customer newnull() { return new NullCustomer(); }... class NullCustomer extend Customer { public boolean isnull() { return true; } }

121 class Customer... public boolean isnull() { return false; } protected Customer() {} // clients do need to not know about null class } static Customer newnull() { return new NullCustomer(); }... class NullCustomer extend Customer { public boolean isnull() { return true; } } compile

122 class Site... Customer getcustomer() { return (customer == null)? Customer.newNull(): customer; } Customer customer = site.getcustomer(); BillingPlan plan; if (customer.isnull()) plan = BillingPlan.basic(); else plan = customer.getplan(); String customername; if (customer.isnull()) customername = occupant ; else customername = customer.getname();

123 class Site... Customer getcustomer() { return (customer == null)? Customer.newNull(): customer; } Customer customer = site.getcustomer(); BillingPlan plan; if (customer.isnull()) plan = BillingPlan.basic(); else plan = customer.getplan(); String customername; if (customer.isnull()) customername = occupant ; else customername = customer.getname(); compile and test

124 class NullCustomer... public Plan getplan() { return BillingPlan.basic(); } Plan customerplan = customer.getplan();

125 class NullCustomer... public Plan getplan() { return BillingPlan.basic(); } Plan customerplan = customer.getplan(); compile and test

126 class NullCustomer... public String getname() { return occupant ; } String customername = customer.getname();

127 class NullCustomer... public String getname() { return occupant ; } String customername = customer.getname(); compile and test