MSO Lecture 11. Wouter Swierstra (adapted by HP) October 23, 2017

Transcription

1 1 MSO Lecture 11 Wouter Swierstra (adapted by HP) October 23, 2017

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

3 3 TODAY Object oriented analysis: The analysis matrix Design patterns: Recursion and the Decorator pattern The Model-View-Controller pattern The Observer pattern

4 4 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?

5 5 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.

6 VARIATIONS, VARIATIONS, VARIATIONS... 6

7 7 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?

8 8 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.

9 9 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.

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

11 11 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

12 12 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

13 13 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

14 14 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

15 15 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).

16 16 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.

17 17 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.

18 18 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.

19 19 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. So far for the Analysis matrix.

20 EVER HEARD OF RECURSION? 20

21 21 TOWARDS THE DECORATOR PATTERN pannenkoek pannenkoek pannenkoek pannenkoek pannenkoek stroop bosbessenjam spek kaas ui

22 22 INNOVATION & CHANGING REQUIREMENTS pannenkoek stroop pannenkoek bosbessenjam pannenkoek spek pannenkoek kaas pannenkoek ui pannenkoek champignons pannenkoek spek & kaas pannenkoek spek & stroop pannenkoek ui & champignons pannenkoek spek & kaas & stroop speltpannenkoek stroop speltpannenkoek bosbessenjam......

23 23 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 (You should recognize the Strategy pattern.)

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

25 25 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....

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

27 27 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?

28 28 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.

29 29 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.

30 30 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 Example: stroop kaas spek speltpannenkoek How can we organize this in a design?

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

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

33 33 APPLYING THE DECORATOR PATTERN The sales order example: print() Receipt BaseReceipt print() Receipt Decorator print() LoyaltyPoints Decorator print() ExportFees Decorator print()

34 KEEP ORDER! Note that you can call the next receipt(decorator) before or after executing the component. class LoyaltyPointsDecorator : ReceiptDecorator { public void print() { Console.WriteLine("10 points earned"); receipt.print(); } } The order we choose determines whether we get headers or footers. Question: is LPD a header or a footer? 34

35 35 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()));

36 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! 36

37 37 ORDERING EXAMPLE - II new Header1 (new Header2 (new Footer1 (new BaseReceipt()))); Order matters! But beware: the creation order is important for the processing order of the headers w.r.t. each other the creation order is important for the processing order of the footers w.r.t. each other the order of the recursive method call determines whether it is a header or a footer

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 SOFTWARE ARCHITECTURE DEFINITION According to Wikipedia: Software architecture describes the high-level structure of a software system.

41 41 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)

42 42 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)

43 43 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?

44 44 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

45 45 ARCHITECTURAL PATTERNS We will mentionone 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.)

46 46 PROBLEM: A BOARD AND PIECES GAME Suppose you need to (re)implement a board and pieces 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?

47 47 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.

48 48 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

49 49 MODEL-VIEW-CONTROLLER IN A DATABASE APPLICATION The Model is the database schema The View defines the GUI s for data entry and displaying query results The Controller defines the control flow and assembles/launches the SQL code

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

51 51 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, GP, MOP, such as the calculator, TickTick or the drawing program. Can you recognize MVC structures?

52 52 COMMUNICATION How do the Model, View, and Controller communicate? When a new piece is placed in Reversi, how does the Model get updated? They are good candidates for using the Observer pattern.

53 53 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...

54 54 OBSERVER PATTERN: CASE STUDY We could hard-code this: class Customer { public void addcustomer() { server.welcomecustomer(); postoffice.verifyaddress(); database.addcustomer(); } } Doesn t seem very cohesive..., but it can get even worse.

55 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? 55

56 56 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.

57 57 TERMINOLOGY ISSUES: BOOK VS. C# IOBSERVER update() corresponds to Notify() attach() corresponds to Register() detach() corresponds to UnRegister() The terms update(), attach(), detach() are used in the book, where the authors define their own interface. The equivalent terms Notify(), Register(), UnRegister() match the C#-interface.

58 GENERAL OBSERVER PATTERN 58

59 59 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.

60 STEP 1: ESTABLISH A COMMON INTERFACE public interface IObserver { void Notify(object anobject); }... class PostOffice : IObserver... void Notify (Customer mycustomer) // do the required stuff here In our example, the server and post office would need to define Notify methods. 60

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, implementing this interface: 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: void notifyobservers () { 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 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.

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