Software Engineering and Architecture Hints on Broker II

Software Engineering and Architecture Hints on Broker II Mandatory

Broker II • Learning Goal – Get the return object reference methods implemented • get. Unit. At(p), and cousins. . . – Get the Invoker code integrated – Get the Mini. Draw GUI integrated in a full client • Product Goal – JUnit test suite that cover all broker related code – System testing of a full Hot. Civ GUI based product! Wow! CS@AU Henrik Bærbak Christensen 2

Broker 2. 1 • TDD the Game methods that return object references. • That is, write JUnit tests that implement the FRDS process AU CS Henrik Bærbak Christensen 3

Broker 2. 1 • Hmmm… It is a ‘get. Unit. At(2, 1)’ right – So – the Client gets an object. Id – Create a Proxy around it and return that reference • Yeah – but what about the second time you invoke – and get the same object. Id – ? AU CS Henrik Bærbak Christensen 4

Broker 2. 1 • What about Tile? AU CS Henrik Bærbak Christensen 5

Broker 2. 2 • Integrate the Invokers from last exercise, ensure that they are split into sub invokers. • That is, remove the fakeit object. Id code parts from last exercise, and refactor to use multi type dispatch. AU CS Henrik Bærbak Christensen 6

Broker 2. 2 • Integrate the Invokers from last exercise, ensure that they are split into sub invokers. • That is, remove the fakeit object. Id code parts from last exercise, and refactor to use multi type dispatch. Make ‘lookup. City’ use a name service AU CS Henrik Bærbak Christensen 7

2. 3 System Testing Gui, Client, Observer? ? ?

The Grand Finale System Testing. Story: Pedersen and Findus play a game of Hot. Civ Disclaimer: Screenshot is a Integration Test AU CS Henrik Bærbak Christensen 9

Observer so far • There are two observers – Both Servant and Client. Proxy have one • Last Iteration – Made them shut up… • It works well because – What is the role of the Observer? – To inform the GUI about state changes in the Game domain – And – we had no GUI AU CS Henrik Bærbak Christensen 10

But Civ. Drawing Observes Game • From the Iteration 8 exercise, the Minidraw Drawing role have to observe on Subject Game Now, Civ. Drawing will be notified about events in the Game, like world. Changed. At(p) AU CS Henrik Bærbak Christensen 11

But. . . • So – requirements collide here – GUI can only update based on Observer events from Game – FRDS. Broker insists on not making a remote observer possible because it only supports passing value objects from client to server – AU CS Henrik Bærbak Christensen 12

So What? • I suggest to take a crude and implementation-wise cheap route instead. . . AU CS Henrik Bærbak Christensen 13

Observer on the Client. Proxy • We simply implement the Subject behaviour in the Game. Client. Proxy as usual, ala Sorry, ought to be an observer list • Exercise: – What do we achieve by that? – What do we NOT achieve? AU CS Henrik Bærbak Christensen 14

Client Manual Refresh • Introducing the (ugly) refresh button – In Gfx. Constants • Update your Composition. Tool so mouse. Up() events on button call the Drawing role’s request. Update() – editor. drawing(). request. Update() AU CS Henrik Bærbak Christensen 15

Discussion • Does this have a flavour of being tacked on? • Yep! But still ‘refresh’ is not uncommon : • Alternative: Optional Exploration Exercise – Make server side observer that keeps log of state events with a incrementing sequence number (index in array may suffice) – Make a client side observer that periodically poll the server to fetch a list of all stateevents since the last fetched event • get. Events. Since. Event. With. ID(47) or something like that. . . – Alternative: long polling method call… AU CS Henrik Bærbak Christensen 16

Conclusions Happy Coding. . . Post/Mail in case if unforseen problems!!!