MSO Lecture 11. Wouter Swierstra. October 15, 2015

Transcription

1 1 MSO Lecture 11 Wouter Swierstra October 15, 2015

2 2 REVIEW Object oriented analysis: RUP; requirements; use cases; domain models; GRASP principles; Design patterns: Facade Bridge Strategy Abstract Factory...

3 3 BUT REALLY... What makes great code? Thinking in terms of responsibilities. Principles of good design: Favor aggregation over inheritance; Program to an interface not an implementation; Find what varies and encapsulate it. What is the process of software design?

4 4 ANALYSIS We ve seen different techniques for analyzing a problem domain: noun-verb analysis; commonality variability analysis. Today, we ll add one more tool to the toolbox: the analysis matrix.

5 VARIATIONS, VARIATIONS, VARIATIONS... 5

6 6 HANDLING VARIATION A lot of systems grow complex quickly because they need to handle a lot of special cases, variations, etc. Look out for examples the next time you fill in a tax form. This creates headaches for analysts. How can we design software that can handle this well?

7 7 THE ANALYSIS MATRIX 1. Identify the most important features in a particular scenario and organize them in a matrix. 2. Proceed through other scenarios, expanding the matrix as necessary. 3. Expand the analysis matrix with new concepts. 4. Use the rows to identify rules. 5. Use the columns to identify specific situations. 6. Identify design patterns from this analysis. 7. Develop a high-level design.

8 8 CASE STUDY: E-COMMERCE REQUIREMENTS Build a sales order system for Canada and the USA; Calculate freight based on the country we are in. Money will be handled in the country we are in. In the USA, tax will be calculated by state. Use US Postal rules for verifying addresses. In Canada, use FedEx for shipping and Government Sales Tax and Provincial Sales Tax.

9 9 IDENTIFY VARIATION We have one important distinction to make: When the customer is in the USA; When the customer is in Canada.

10 10 THE ANALYSIS MATRIX Start identifying the key features of one case: selling in the USA. US Sales Calculate freight Use UPS rates Verify address Use US postal rules Calculate tax Use state and local taxes Currency US Dollars

11 11 GROWING THE MATRIX Calculate freight Verify address Calculate tax Currency US Sales Use UPS rates Use US postal rules Use state and local taxes US Dollars Canadian Sales

12 12 GROWING THE MATRIX US Sales Canadian Sales Calculate freight Use UPS rates Verify address Use US postal rules Calculate tax Use state and local taxes Currency US Dollars Canadian Dollars

13 13 GROWING THE MATRIX US Sales Canadian Sales Calculate freight Use UPS rates Use FedEx rates Verify address Use US postal rules Canadian postal rules Calculate tax Use state and local taxes Use GST and PST Currency US Dollars Canadian Dollars

14 14 IN PRACTICE... It does not always play out so nicely... But that is a Good Thing! The analysis matrix can help point out gaps in the requirements. For example, in Canada the maximum weight FedEx will handle is 31.5 kg now you can ask your customer if there is a maximum weight for US shipments (they probably forgot to mention this).

15 15 EXTENDING THE DESIGN As you add new countries, you may uncover further variation, adding new rows: For instance, shipping to the Netherlands means: handling a new currency; but also handling a different date format.

16 16 WORKING WITH CUSTOMERS Customers know the problem domain extremely well. They do not think like Computer Scientists or Information Scientists they talk about specific examples. When they say always, they mean usually. When they say never, they mean rarely. Organizing information in this matrix can guide customer interaction.

17 17 IDENTIFYING RULES The different rows correspond to different implementations of some general concept: calculating shipping rates; formatting dates. Implementing this variation can be done in different ways: the class itself may be responsible for the variation, such as formatting Dates; you may want to introduce a design pattern (such as the Strategy, Bridge, or Decorator) to encapsulate the variation.

18 18 ISN T THIS THE SAME AS CVA? Yes and no. Both a CVA and Analysis matrix identify variation in your domain. The focus is very different: A CVA is domain-model driven and classifies conceptual classes according to their commonality/variation. An analysis matrix is use-case driven and structures the available information and helps identifies missing information. Their closely related, but complementary techniques.

19 19 TOWARDS THE DECORATOR PATTERN Suppose we have our SalesOrder class, capable of handling different tax calculations. SalesOrder + process() + printreceipt() CalcTax calculatetax(price : double) NLTax UKTax

20 20 CHANGING REQUIREMENTS... But now suppose that we need to print receipts as well SalesOrder + process() + printreceipt() Receipt + print() CalcTax calculatetax(price : double) NLTax UKTax

21 21 RECEIPT PRINTING Each sales receipt may be decorated with additional information in the header and footer: address and tax information; customer loyalty points, if applicable; import/export fees, if applicable; discount code for your next order, if applicable....

22 22 FIRST SOLUTION SalesOrder + process() + printreceipt() Receipt + print() CalcTax calculatetax(price : double) Header + print() Footer + print() NLTax UKTax

23 What do you think of this solution? 23

24 24 CRITIQUE This will work but: you need to include a lot of switches in the Header and Footer classes to decide what to print (bad code smell); you will mix the code that prints the headers with the control code, deciding which headers to print (weak cohesion); Can we do better?

25 25 USE THE STRATEGY PATTERN We can use the Strategy pattern to print the header and footer information. But what if we want to print more than one header and/or footer at a time? we need to reorder the headers and/or footers? The Strategy pattern may not be the best solution.

26 26 THE DECORATOR PATTERN The Gang of Four describe the intent of the decorator pattern as: Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative for extending functionality.

27 27 A CHAIN OF DECORATORS Intuitively, you can think of decorators as a chain of Decorator objects that all add some new functionality to concrete component. Decorator A Decorator B Decorator C Concrete Component How can we organize this in a design?

28 28 THE DECORATOR PATTERN Component operation() Concrete operation() Decorator operation() Concrete DecoratorA operation() Concrete DecoratorB operation()

29 29 EXERCISE It s January and everyone has New Year s Resolutions. The Coffee Bar where you work wants to make people more aware of their calorie intake. Can you help adapt their software to display this? A basic espresso has 10 calories; Adding skimmed milk adds 100 calories; Adding whole milk adds 200 calories; A flavour shot adds 80 calories; An extra shot of espresso adds 10 calories. How can the decorator pattern help solve this problem?

30 30 THE DECORATOR PATTERN Component operation() Concrete operation() Decorator operation() Concrete DecoratorA operation() Concrete DecoratorB operation() This Decorator class has a recursive component; It uses a two-level deep inheritance hierarchy for good reason!

31 31 APPLYING THE DECORATOR PATTERN print() Receipt BaseReceipt print() Receipt Decorator print() LoyaltyPoints Decorator print() ExportFees Decorator print()

32 32 PITFALLS ORDER Note that you can call the next decorator before or after executing the component. class LoyaltyPointsDecorator : ReceiptDecorator { public void print() { Console.WriteLine("10 points earned"); receipt.print(); } } We are free to choose the order this determines if we want headers or footers!

33 33 ORDERING EXAMPLE - I To produce: Header1 Base receipt Footer1 We assemble the following receipt: new Header1(new Footer1(new BaseReceipt())); Or equivalently: new Footer1(new Header1(new BaseReceipt()));

34 ORDERING EXAMPLE - II To produce: Header1 Header2 Base receipt Footer1 We assemble the following receipt: new Header1 (new Header2 (new Footer1 (new BaseReceipt()))); Order matters! 34

35 35 ANOTHER DECORATOR EXAMPLE Suppose I have a TextField storing some text. As more text is added, I need to add scroll bars. Sometimes, I want to add a visible border (depending on the background).

36 36 DECORATOR AGAIN TextView TextField Decorator BorderDecorator +borderwidth: int ScrollBar Decorator + scrollup() + scrolldown() Any problems with this design?

37 37 TROUBLE WITH DECORATORS You can only call the specific methods that are defined if you happen to know how a TextField is built up if (myview.gettype() == typeof(scrollbardecorator)) { // the TextField has a ScrollBar // (at the highest level) myview.scrollup(); } Which rule of good design gets broken?

38 38 DECORATORS IN OO LANGUAGES I/O in C# and Java uses lots of decorators: C# defines an abstract Stream class with methods like BeginRead and Close; There are concrete instances for writing to a file, network socket, etc. Using decorators, you can define your own instance that: decrypts the data; zips the data; buffers data; converts the data;...

39 DECORATOR REVIEW Intent: Attach additional responsibilities to an object dynamically. Problem: The object you want to use does the basic functions you require. However, you may need to add some additional functionality to the the object, occurring before or after the object s basic functionality. Solution: Allows for extending the functionality without resorting to subclassing. Participants: The ConcreteComponent is the base class, that is extended with Decorators. Their common abstract superclass, Component, defines the interface for both the ConcreteComponent and Decorator classes. Consequences: The functionality that needs to be added should be done in (small) Decorator objects. These decorator objects can then be dynamically wrapped around the ConcreteComponent as necessary. 39

40 40 COMPOSITE PATTERN Students who have taken the course on Functional Programming will be familiar with algebraic data types: data Tree = Leaf Int Node Tree Tree sum :: Tree -> Int sum (Leaf x) = x sum (Node l r) = sum l + sum r The Composite pattern is similar to the Decorator pattern. It allows you to write such recursive data structures in an object oriented language.

41 41 COMPOSITE PATTERN + sum() : int Tree 2 Leaf + value : int + sum() : int Node + sum() : int

42 42 WHY SOFTWARE ARCHITECTURE? This is a course about object oriented analysis and design. But I want to say a few words about software architecture, even if it is covered in other courses. This is particularly relevant for the final projects.

43 43 SOFTWARE ARCHITECTURE DEFINITION According to Wikipedia: Software architecture describes the high-level structure of a software system.

44 44 SOFTWARE ARCHITECTURE DEFINITION Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns. (According to Kruchten, Booch, Bittner, and Reitman)

45 45 SOFTWARE ARCHITECTURE DEFINITION The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system s lifetime; and, in the end, architecture boils down to whatever the important stuff is. (According to Fowler, emphasis is mine)

46 46 ARCHITECTURAL DECISIONS How will the users be using the application? Where is data stored? How will the application be deployed? How will it be maintained?

47 47 ARCHITECTURAL PATTERNS Just as we have seen design patterns, there are numerous architectural patterns: Component-based Data-centric Event-driven (or Implicit invocation) Layered Peer-to-peer Pipes and filters Plug-ins

48 48 ARCHITECTURAL PATTERNS I want to cover one pattern that is more architectural in flavour than many of the design patterns we have seen so far, Model-View-Controller. Why do this? It is very useful for the final lab project. It helps you understand that patterns appear on different levels during software design. It might motivate you to study such patterns further. (MVC is actually discussed in the first pages of the Gang of Four book it s a classic pattern that predates many of the design patterns we ve seen so far.)

49 49 PROBLEM: REVERSI Suppose you need to (re)implement a Reversi game. What do you need to do? Logic for handling the moves; Graphics for the board and pieces; Interaction with the users. How should you assign these aspects to classes?

50 50 MODEL-VIEW-CONTROLLER The MVC is a triple of classes or components: The Model is responsible for storing the data; The View is responsible for visualizing data; The Controller is responsible for user interaction.

51 51 MODEL-VIEW-CONTROLLER ON THE WEB If you re familiar with webprogramming, you may find the following analogy useful: The Model is the data in an HTML page; The View is the CSS file describing how it should be displayed; The Controller is your browser that lets you view and navigate a webpage.

52 52 MODEL-VIEW-CONTROLLER initiate operation Model report events report events read data Controller update view send events View (This is not an UML diagram!)

53 53 WHY USE MVC? Strong cohesion responsibilities are clear. Decoupled different responsibilities: Allows for multiple views of the same data think of Excel! or completely different controllers. or change the way a view responds to the controller. Makes communication clear. Most of the domain logic should be in the Model. Exercise: Have a look at some of the code examples from IMP, such as the calculator or drawing program. Can you recognize MVC structures? What about your Reversi program?

54 54 COMMUNICATION How do the Model, View, and Controller communicate? When a new piece is placed in Reversi, how does the Model get updated? They actually use the Observer pattern.

55 55 OBSERVER PATTERN: CASE STUDY Suppose I get yet another new requirement for my online webstore. Whenever a new customer registers, we should: send a welcome to the customer; verify the customer s address with the post office; update our data base;...

56 56 OBSERVER PATTERN: CASE STUDY Are these all the requirements? It seems unlikely. We could hard-code this: class Customer { public void addcustomer() { database.addcustomer(); server.welcomecustomer(); postoffice.verifyaddress() } } Doesn t seem very cohesive...

57 OBSERVER PATTERN: GAMES Alternatively, what if you re writing a simple mobile game with a bunch of achievements that can be unlocked: when you defeat 100 enemies; when you die 10 times; when you have scored 1 million points;... Who checks when you earn an achievement? You want to keep the achievement checks separate from the main game code; But when certain events happen (enemy defeated, death, etc.) you may want to inform another class to check whether a new badge has been earned. How can you set up this communication effectively? 57

58 58 OBSERVER PATTERN: INTENT To define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated. It s also known as the Publish-Subscribe model or Dependents.

59 59 CVA Different kinds of objects - there are all kinds of objects that may be interested in new customers. Different interfaces - as these objects may belong to different classes, they have different interfaces.

60 60 STEP 1: ESTABLISH A COMMON INTERFACE In order to treat all the interested objects, or Observers, we need to establish a common interface. This could be using subclasses, but typically you may want to use an interface. C# has a special IObserver interface for precisely this purpose: public interface IObserver { void Notify(object anobject); } In our example, the server and post office would need to define Notify methods.

61 61 STEP 2: REGISTER THE OBSERVERS Let anyone interested in knowing about new customers register themselves. To do that, we add two methods to the Customer class: public interface IObservable { void Register(IObserver anobserver); void UnRegister(IObserver anobserver); } Now anyone interested in new customers can Register.

62 62 STEP 3: NOTIFICATION Now when a new customer is added, we can notify any observers interested in that event: foreach(iobserver anobserver in myobservers) { anobserver.notify(anobject); } This could be that a new customer is registered, but also, for example, that an existing customer changes address.

63 63 STEP 4: EXPOSING FURTHER INFORMATION Perhaps the observers need further information about the Customers. You may want to revisit your design and make sure they have access to the necessary information, like addresses.

64 64 APPLYING THE OBSERVER PATTERN Observer +update() Welcome Letter +update() Address Verification +update() Customer +attach() +detach() +notify() +getstate() +setstate() Question Why use interfaces rather than inheritance? We can also make the IObservable aspect of the customer explicit.

65 65 HANDLING NEW REQUIREMENTS Suppose we also want to send customers discount coupons for the nearest store, once they register online. What would need to change?

66 66 APPLYING THE OBSERVER PATTERN Observer +update() Welcome Letter +update() Address Verification +update() Customer +attach() +detach() +notify() +getstate() +setstate() Typically, we use interfaces rather than inheritance. We can also make the IObservable aspect of the customer explicit.

67 67 GENERAL OBSERVER PATTERN Observable +register() +unregister() Observer +notify() Concrete Observable +notifyobservers() +getstate() +setstate() Concrete Observer +update()

68 68 PITFALLS The Observer pattern is useful in when the list of Observers can vary: not all requirements are known yet; the observers change dynamically;... Otherwise, it adds unneccessary overhead. C# also has special event classes for defining Observers.

69 69 FILTERING EVENTS What if not all observers are interested in all events?

70 70 FILTERING EVENTS What if not all observers are interested in all events? Apply the Strategy pattern: Each observer has an associated Strategy, deciding whether or not it is interested in a certain event; When the Customer sends out notifications, it uses the strategy to decide whether or not to notify various observers.

71 71 MATERIAL COVERED Design Patterns explained. Chapter Model-view-controller.