Miki Guest lecture at Abo Akademi University

Transcription

1 Miki Guest lecture at Abo Akademi University

2 Why? Architectural styles MVC MVP Vaadin UI architecture Agile and architecture

3 What makes architecture so crucial

4 Architecture is about ENABLING things Efortlessly Nobody notices a good architecture Architecture is language-agnostic Implementation, however, is not Architecture is not just high-level design Choose wisely Bad choice = problems Good choice = nothing happens Nobody notices a good architecture miki@vaadin.com 5

5 Be flexible No solution works 100% of the time Mix architectural styles Requirements change Foresee Requirements change Experiment Requirements change Being unprepared costs Requirements change The bigger the change, the higher the cost The later the development stage, the higher the cost

6 What you already know

7 Data independent Any filter can take output of any other filter Processing order is irrelevant Multithreading, pre-processing, optimisation Common interface for data and filters

8 Processing multidimensional images Multi-disciplinary research project between UTU and AAU, among others Free and open source

9

10 Acquire Process Display Save Open file from disk Modify and analyse the image Show the result Change processing parameter Store results to disk

11 «interface» BioData -stack 1 1 -channels 1 -timepoints * -parent * -parent * -parent «interface» BioChannelData «interface» BioTimepointData «interface» BioStackData miki@vaadin.com 12

12 «interface» FileWriter Visualisation +write(in name : string, +activate() in data : BioData) +deactivate() LSMWriter AbstractVisualisation T extends BioTask #makedrawingcontents() «interface» #makesettingscontents() #showdata() Process #getactivedata() #getconfig() SeriesWriter +gettaskinstance() : T extends BioTask +getguifortask() : Component +getsupportedtaskclass() : T extends BioTask «interface» BioTask Gallery +execute() : BioData +getsourcedata() : BioData +setsourcedata(in data Visualisation3D : BioData) «interface» BioData BX2Writer Orthogonal miki@vaadin.com 13

13

14

15

16 Client-server with additional layer(s) Data Presentation Communication Encryption Clear separation Requires defined communication protocols Scales up as needed

17 Multi-platform board game Central game server Fun and challenging Developed for project course! :)

18

19

20

21

22 Originally a design pattern Thanks, GOF Now an architectural style There is no MVC standard Implementations differ MVC is present in both described projects You would have problems identifying it Evolving pattern miki@vaadin.com 23

23 Ruby on Rails, anyone? Pretty good implementation Convention over configuration Ruby is awesome, by the way

24 Problem domain Data UI-agnostic May be a facade Real data hidden Active or passive Broadcasts events active Most often Requires polling or querying passive miki@vaadin.com 25

25 Displays the model Current state Possible to change viewing parameters Only focused on presentation Typically, UI Can you think of other types of views?

26 Manages the business logic Modifies model Modifies view parameters May listen to view and model changes Affecting the number of available commands

27 BioData Facade Real implementation determined by a file reader Passive Implicitly asked by each filter miki@vaadin.com 28

28 Visualisations File writers Data-source independent Relies on the data interface Queries the state explicitly No methods to modify the data Just to change view parameters

29 Executable Queries model Selected file type matters Queries data User constructs processing pipeline Reacts to UI changes Listens to views

30 Game state Concrete object Active Broadcasts events Proxy Real data is on the server

31 UI of the client application Model is proxied Events are sent by the server

32 Client applications are proxies User actions are translated to server commands Server Modifies game state based on commands Sends responses to interested clients

33

34 Enhanced MVC Abstracts presentation logic View is an interface Can be switched to something else

35 Problem domain Data interface The same as in MVC

36 Interface Implementations are passive No modifications of the model All actions are deferred to the presenter Presenter: savedata(); View: onbuttonclick() { presenter.savedata(); } Unaware of how data is modified Though typically creates a presenter miki@vaadin.com 37

37 Concrete object Modifies data In response to calls from views Updates view In response to events from model Unaware of how the data is displayed

38 Something we strongly encourage No UI dependencies in Presenter No dependencies to business logic in View Model is just the data Allows many different UIs Mobile Browser Even non-vaadin! That we do not encourage

39 Not sure Personal opinion MVC: View is concrete and active Knows about what commands to send to controller MVC: Controller is an entry point MVP: View is abstract and passive Just calls the presenter Usually knows the method Can be decoupled to just send events instead MVP: View is an entry point MVP: not for non-interactive UIs

40

41 Amazing web applications made easy }> Web-app framework Java Requires servlet container Or application server Open source Friendly community

42 Two-tier approach Server (application container) Client (browser) Two tiers there as well rendering and communication Event-based Client events Server RPC calls RPC = Remote Procedure Call HTTP (Ajax) request Server events State change / Client RPC calls HTTP (Ajax) response miki@vaadin.com 43

43

44

45 Server-side change to the state RPC method call to server (State serialisation and deserialisation) Await user interaction Update widget based on state

46 Widget Connector Shared state Component Browser only Can use RPC Updates widget Reads shared state From server to client Server only Can use RPC

47

48 We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over Processes and tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan That is, while there is value in the items on the right, we value the items on the left more miki@vaadin.com 49

49 Iterative Short cycles Working product Each cycle adds value Not necessarily new things! Each cycle produces working code Customer gives feedback after every cycle Team is responsible Everyone works Everyone s input is equal Everyone is credited for success Everyone gets blamed for failure Liberté, égalité, fraternité miki@vaadin.com 50

50

51 No up-front design in agile Adapt! Respond! Instant feedback! No waste Not related to current implementation = waste Focus on delivering what is important Working software is miki@vaadin.com 52

52 Architecture is about ENABLING things The better it is, the more you can do Changes are expensive later on More code to rebuild Changes will come Agile gives a way to introduce changes Frequently Accurately Requirements change Being prepared for the worst does not prevent the worst from happening miki@vaadin.com 53

53 Understand Explicit requirements Implicit requirements Look ahead Usually you know more than just a current cycle Foresee Certain things are bound to happen miki@vaadin.com 54

54 Customer: we want in this class to treat nulls as if they are empty strings Me: what about other types? Customer: no other types, it should always be treated as an empty string Me: sure, we will do it * System goes into production * * Next day * Customer: we have this case here where in that class we want to treat null as zero What would you do? miki@vaadin.com 55

55 Comes with experience Read, look, ask Spend some time Ask other team members Find balance Some changes are more probable Some solutions are easy to implement Learn by mistakes Customer is always right Customers learn usually really fast

56

57 Architecture is about ENABLING things It is much more than high-level design Nobody notices a good architecture It never works for the first time Predict change Prepared be, young Padawan Architecture is not static Learn by mistakes miki@vaadin.com 58

58 A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away. Antoine de Saint-Exupery

59 Questions? Comments?