CSE 3311 Software Development Observer Pattern Dept of

CSE 3311 – Software Development Observer Pattern Dept. of Computer Science & Engineering, York University, Toronto 1

Weather-O-Rama Inc Statement of Work Ø Ø Ø Congratulations on being selected to build our next generation of internet based weather monitoring station. Details follow below. We look forward to seeing your design by tomorrow night! Sincerely John Hurricane CEO P. S. We are overnighting the WEATHER_DATA source files to you 2

Weather-O-Rama Current Conditions Temp: 73 F Humidity: 60 Pressure: Statistics Avg. Temp: 62 F Min. Temp: 50 F Max. Temp: 78 F … other views …. . Hardware provided by Weather-O-Rama Class WEATHER_DATA must satisfy a specified interface so that the Weather Station can signal a change. It then updates its displays for current conditions, statistics etc. What must we implement? Create an app that updates the various displays real-time 3

4

We are provided with deferred class WEATHER_DATA feature -- weather data available to observers temperature: REAL humidity: REAL pressure: REAL correct_limits (t, ensure Result implies p, h: REAL_32): BOOLEAN -36 <= t and t <= 60 -- o. C 50 <= p and p <= 110 -- KPa 0. 8 <= h and h <= 100 --%RH measurements_changed -- called from weather station after a set_measurements (t, p, h: REAL_32) -- called from weather station require correct_limits (t, p, h) invariant end correct_limits (temperature, pressure, humidity) Must complete this code 5

Ø We are provided with class WEATHER_DATA Ø But this class is closed for business 6

First Design Use Inheritance Open Closed Principle class WEATHER_DATA_IMP inherit WEATHER_DATA feature current_conditions: CURRENT_CONDITIONS statistics: STATISTICS forecast: FORECAST. . . Problems? Nice common “update” interface measurements_changed do current_conditions. update(temp, humidity, pressure) end 7

Problems? Part that changes Ø Is update coded to concrete implementation, or to interfaces? Ø Do we need to add code to the class for each new display? Ø Can we add/remove new displays from a client at runtime? Ø Have we encapsulated that which changes? 8

Observer: ONE MANY relationship Observers: automatic update Subject Weather Data Current Conditions Display Forecast Display Statistics Display 9

Observer Pattern Ø Intent Ä Define one-to-many dependency Ø When one subject changes state, all observers are notified and correspondingly updated Ø Also known as Ä Publish-Subscribe 10

Observer – Motivation text view Notify change target view A is 30% B is 50% C is 20% bar view Observers Request modification rectangle view 11

Observer Architecture – Example SUBJECT OBSERVER * observers : SET[…] attach(observer) detach(observer) notify subject TEXT_VIEW get_state subject update * TARGET_VIEW update + + BAR_VIEW update + + RECTANGLE_VIEW update + + 12

Observer – Abstract Architecture SUBJECT observers : LIST[…] OBSERVER * update * attach(observer) detach(observer) notify o: observers • o. update CONCRETE_SUBJECT get_state set_state Current. notify subject CONCRETE_OBSERVER update + + subject. get_state 13

Observer – Scenario Ø Concrete subject updates all observers, when state is changed by a client CLIENT Scenario: Update observers 1 set_state 2 notify 3 update 4 get_state 2 1 CONCRETE_SUBJECT 3 4 CONCRETE_OBSERVER 14

UML 15

deferred class OBSERVER feature -- to be effected by a descendant update -- update the observer's view of the subject deferred ensure up_to_date_with_subject end OBSERVER * update * How can we ensure that the update worked? up_to_date_with_subject: BOOLEAN -- is this observer up to date with its subject deferred end 16

class SUBJECT create make feature -- invoked by a SUBJECT attach(observer) detach(observer) notify observers: LIST [OBSERVER] -- list of observers attached to this subject attach (o: OBSERVER) require o /= Void and not observers. has(o) ensure observers. has(o) detach (o: OBSERVER) … notify … 17

class SUBJECT feature … observers: LIST [OBSERVER] … attach (o: OBSERVER) … detach (o: OBSERVER) … SUBJECT attach(observer) detach(observer) notify -- Send an `update' message to each observer o do from observers. start until observers. after loop observers. item. update; observers. forth end ensure observers. for_all (agent (o: OBSERVER): BOOLEAN do Result = o. up_to_date_with_subject end) invariant observers_not_void: observers /= Void 18 end

back to Weather-O-Rama Ø Ok, so what classes will we need? Ø Sketch a BON diagram 19

back to Weather-O-Rama Ø WEATHER_DATA is closed; so inherit from it Ø How to use the observer pattern? Multiple inheritance • Is-a WEATHER_DATA • Is-a SUBJECT 20

Inherit weather data behaviour such as temp, pressure, humidity Inherit subject behaviour such as • add an observer (display) • notify all observers Effect measurements changed via notify 21

What about the displays 22

Displays 23

class CURRENT_CONDITIONS inherit OBSERVER create make feature {NONE} -- initialize make (wds: WEATHER_DATA_SUBJECT) do weather_data : = wds weather_data. attach (Current) end feature weather_data: WEATHER_DATA_SUBJECT temperature: REAL_32 humidity: REAL_32 Attach the current display to the weather data subject -- subject update -- update the observer's view of subject do temperature : = weather_data. temperature humidity : = weather_data. humidity display end. . . end 24

class CURRENT_CONDITIONS inherit OBSERVER create make feature {NONE} -- initialize make (a_weather_data: WEATHER_DATA_SUBJECT). . . feature • It is easy to forget weather_data: WEATHER_DATA_SUBJECT -- subject to synch temperature: REAL_32 humidity: REAL_32 • A contract failure update. . . will remind you, if you forget to do this up_to_date_with_subject: BOOLEAN -- is this observer up to date with its subject do if temperature = weather_data. temperature and humidity = weather_data. humidity then end display. . . end 25

Power up weather station class WEATHER_STATION create make feature cc: CURRENT_CONDITIONS -- displays fd: FORECAST sd: STATISTICS wd: WEATHER_DATA_SUBJECT make do create wd. make create cc. make (wd); create fd. make (wd); create sd. make (wd) wd. set_measurements (15, 60, 30. 4); wd. measurements_changed wd. set_measurements (19, 56, 20); wd. measurements_changed wd. set_measurements (11, 90, 20); wd. measurements_changed end 26

27

Design Principle: Strive for loosely coupled designs between objects that interact. • OOSC 2: Chapter 3 on modularity • Direct mapping principle • Few interfaces principle (a module should communicate with as few others as possible) • Small interfaces principle (exchange as little information as possible) • Explicit interface principle (interface obvious from the text) limited • Information hiding • Self documentation principle bandwidth 28

Design Principle: Strive for loosely coupled designs between objects that interact. Ø Loosely coupled designs allow us to build flexible OO systems that can handle change because they minimize the dependency between objects 29

Add a new display for the heat index? 30

Java’s built-in pattern (e. g. in Swing) Cannot use MI 31

32

MVC i. Tunes mp 3 player 33

34

35

By: Prof. H. Roumani CGI: Dynamic Pages HTTP Client NFS File Server CGI Web Server Eiffel CGI/sqlite 3 webapp class WEB_APP inherit CGI SQLITABLE. . . App Server JDB C DB Server 36

Key Characteristics of CGI 1. Browser sends an HTTP request to the Web Server 2. Web Server identifies the request as CGI 3. Web Server dispatches the request to the App Server 4. App Server impersonates the script’s owner 5. App Server runs the script passing the request 6. Script outputs the response to Standard 37

38

39

Google: “Gang of Four” 40