System Architecturecs3249/lecture/system architecture.pdfstyle Architecture ... Extensibility Robustness ... Implemented in C, object-based but not object-oriented. has. CS3249 System

CS3249 System Architecture 1CS3249

System Architecture 11CS3249 System Architecture

System Architecture

Leow Wee KhengCS3249 User Interface Development

CS3249 System Architecture 2CS3249 System Architecture 2CS3249System Architecture 2System Architecture 2CS3249


There are more things inside than outside!


10%

30%

60%

Look-and-Feel Icebergadapted from [IBM92]

Presentation(Look)● visual

representations● aesthetics

Interaction(Feel)● techniques● style

Architecture(Behaviour)● organisation● properties● algorithms


Some interactions are simple open a file

Some interactions are complex zoom an image by

program user entering zoom factor user rotating mouse wheel user dragging image widget

while satisfying various conditions non-negative zoom factor maintain aspect ratio handle images larger than screen size

complexbecause

many“things”interact


At program / object class level program components interact

design and implementation of algorithms

At system level system components interact

software engineering

CS3249 System Architecture 7CS3249 7System Architecture

Software Engineering Principles

Decomposition

Separation of Concern

Abstraction

High Cohesion

Loose Coupling

Extensibility

Robustness

Security

etc...


Basic Architecture

Software System

GUI Backend

35age


Standard widgets keep data that they display. Data is duplicated in GUI and backend.

Convenient for quick update, e.g., repainting GUI.

GUI Backend

35ageview

35data


If multiple views are needed for single data,need to make sure they are consistent.

must synchronise

Backend

35age

spin boxdata

sliderdata


Consider a time table application

Duplication of data in GUI, Scheduler and DB.

Consistency problem: need to synchronise copies of data.

Can we remove duplicates?

timetableDB

time tabledata

GUI Scheduler

time tabledata

schedulingfunctions


Model-View

Split model and view. Model: handles data and manipulation.

View: handles display issues, gets data from model.

Actual data can be stored in external storage, e.g., DB.

timetableDB

GUI

view

Scheduler

time tablemodel

schedulingfunctions

getdata

get /put

data


View can display data in various formatsDate Time

12 Oct 2012 2:00 pm

Oct 12, 2012 2.00 pm

12-10-2012 1400

Can have multiple views for a model.

Row 1 Row 2 Row 3 Row 40

2

4

6

8

10

12

GUI Backend

datamodel


Advantages Less or no redundant data.

Can show multiple views of same data.

Can show small parts of large data.

Loose coupling between model and view. Views can be changed without affecting model.

Item views (widgets) can be reused.

Note Still need to synchronise multiple views of same model.


Many variants...

ViewModel

Model View

PresenterAdapterDelegateControllerWhatever


Classic Model-View-Controller

Main characteristics: Split input handling and display.

Model is passive.

View Model

Controller

modifyupdate

get data

user input


Example sequence: user change data.


Model represents data and operations on data. Stores and retrieves data.

Modify and update data.

View represents display items and display logic. Displays data.

Gets data from model.

Controller accepts user inputs. Translates inputs to service requests for model.

Informs view to update.

Advantage View and controller can change without affecting model.


What if model is changed by other sources? Model needs to inform view to update.

View Model

Controller

modifyupdate

get data

user input

updatetight coupling!

NetworkSource

get data


MVC with Observer

Use observer to decouple model and view. Views register as observers with model.

Model informs observers to update.

Observers inform views to update.

Advantages Views can change without affecting model.

Views are decoupled from model.

Shortcoming Model has to maintain a list of observers.


Method 1: Observer is concrete object.

Observer contains pointer to view.

Observer is coupled to view.

View Model

Controller

modifyupdate

get data

user input

update

NetworkSource

get data

Observer

update


Method 1 sequence


Method 2: Observer is abstract class.

View implements observer interface or inherits observer class.

Different kinds of view appear as same kind of observer.

View can change without affecting observer.

Model

Controller

modifyupdate

get data

user input

update

NetworkSource

get data

Observer

View


Method 2 sequence


Observer in Use: X Windows

HostWindow

X Windows

callbackHelperWidget

Implemented in C, object-based but not object-oriented.

has


Observer in Use: X Windows

Implemented in C, object-based but not object-oriented.

HostWindow

X Windows

callbackHelperWidget

addCallback(widget,event type, callback,data)

get help

user input

callback(widget, data,callback_data)


Observer in Use: VTK

HostWindow

VTK

execute

HelperWidget

has

vtkCommandsubclass

has

Implemented in C++, object-oriented.


Observer in Use: VTK

Implemented in C++, object-oriented.

HostWindow

VTK

execute

HelperWidget

AddObserver(event type,command)

get data

user input

execute(caller, event,data)vtkCommand

subclass

get help


t

Classic MVC was first designed for Smalltalk in 1980s.

Computers in 1980s were not so powerful. Relied on OS to handle inputs and display.

X Window Athena widgets hadn't appeared until late 1980s.

IBM PC Apple Macintosh


t

Strengths Good for applications whose inputs and outputs are handled

by different modules.

Good for supporting non-standard input devices.

Weaknesses View update can be inefficient,

unless observer is used.

Modern GUI widgets can handle standard inputs and display.No need to separate standard inputs and display.


t

Confusion: Different interpretations of “controller” Controller as input handler (classic).

Controller as coordinator between model and view.

Controller as display logic (overlap with view).

Controller as data manipulator (overlap with model).

Controller as central processor / business logic (too heavy).

Controller as ...


Cocoa MVC

Cocoa MVC is different from classic MVC View accepts user actions.

useraction


Cocoa MVC is supported by NSObject

Any NSObject subclass, implements model. NSView

Each UI element is associated with a view. NSController

Controller class, coordinates between model and view.

Cocoa supports 2 types of controllers coordinating controller: coordinate functioning of application

mediating controller: used for binding


Cocoa provides binding between model and view. Automatically synchronise model and view states.


Another method is to bind through mediating controller.

view

controller

model


Strength Model and view are less coupled.

Weaknesses Too much overhead for simple UI operations.

Binding can use up considerable amount of memory.

Binding can be difficult to debug.

In practice, advisable to merge controller into view, or

merge controller into model.


MFC MVC

MFC MVC is also different from classic MVC. MFC MVC is similar to Qt MV.

MFC provides document-view architecture CDocument

Implements model of “document” (data). CView

Implements view; include controller's tasks.

CView(view)

CDocument(model)

get / set data

update

user input


Can use MFC binding to synchronise model and view. Less coupling between model and view.

Can intercept events between model and viewto implement controller.


Model-View-Presenter

Main characteristics: View accepts user inputs; possible with modern widgets.

Some presentation logic is moved from view to presenter.

View Model

Presenter

modifyupdate /display

user input

user input

get data


Single presenter may handle multiple views.

Model can inform view to update thru' observer,like MVC.

Compare with MVC: In MVC, controller accepts user inputs.

In MVP, view accepts user inputs.

In MVC, controller doesn't handle display.

In MVP, presenter handles display.

MVP is used in Dolphin Smalltalk. An earlier Taligent MVP is more complex; omit.


Variation: Passive View MVP View is decoupled from model.

View is a passive displayer.

Presenter determines how to display data.

View Model

Presenter

modifyupdate /display

user input

user input get data


Passive View MVP can be implemented in .Net, Evolution.Net MVP, ASP.NET Web Forms MVP, etc.

Java Swing, Echo2, Google Web Toolkit, etc.

Strengths Tailored to modern widgets which can accept user inputs.

Model and view are decoupled.

Presentation logic in presenter can be auto tested.

Weakness View update may be inefficient,

unless observer is used.

Passive view MVP not suitable for intensive visualisationbecause view doesn't get data from model directly.


Qt Model-View

Main characteristics: Replace controller by delegate.

Delegate edits and renders data in widgets.

View Model

Delegate

user input

edit / renderrequest

modify

get data


Model represents data and operations on data.

View displays data.

View items (widgets) handle inputs.

Delegate edits and renders data in widgets. Default delegate is sufficient for most applications.

Can customise delegate.


Model can inform view to update thru' signals and slots.

Delegate

user input

edit / renderrequest

modify

get dataModel

dataChanged()

View

setData()

loose coupling


Qt support for model-view QAbstractItemModel

Abstract model class. Have many subclasses for list, table, directory, file system,

SQL table, etc. QAbstractItemView

Abstract view class. Concrete subclasses include QListView, QColumnView, QTableView, QTreeView.

QAbstractItemDelegate

Abstract delegate class. Concrete subclasses include QItemDelegate and QStyledItemDelegate.

Can create new subclasses of model, view, delegate.


Strengths Efficient update of view.

Use signals and slots for synchronisation.

Fine control over rendering and editing.

Very loose coupling between model and view.

Very loose coupling between host and helper.





In general

Either

Or

ActiveHost

PassiveHelper

get / set / …

ActiveHost

ActiveHelper

get / set / …

Observer update


In general...

Or (with Qt)

Avoid this

ActiveHost

ActiveHelper

get / set / …

signal-slot

ActiveHost

ActiveHelper

get / set / …

update


Use Which Pattern?

Apply software engineering principles.

Architectural considerations Pick the one that best matches requirements, if applicable.

Make things simple, don't over-design.

Don't go for flashy ideas because they are new.

Implementation considerations Pick the one that is supported by the required platform.

Picking one not supported requires additional coding.

Avoid hidden mechanisms that are difficult to test and debug.

In practice, need to combine several design patterns.


A negative example. Why?





Where is Model in Client-Server App?

Place model at server side Thin client, but view must know network protocol.

Inefficient view update.

View

AppLogic

Model

userinput

client server

userinput

modify

get data

ModelFile


Place model at client side App logic must be at client side to work on model.

Become like stand-alone app with network file service.

View

AppLogic

Model

userinput

client server

userinput

modify

get data

ModelFile

FileServer


Place proxies at client side Thick client, but view is oblivious of server.

Efficient view update.

View

AppLogic

Model

userinput

client server

userinput

modify

get data

ModelFile

Modelproxy

getdata

Appproxy


Summary

Model-view reduces coupling of model and view.

MVC separates input handling and display.

Various interpretations of 'C' in MVC.

Qt MV uses delegate for editing and rendering.

Practical software architecture must integratemodel-view pattern with other design patterns.

Apply software engineering principles.


Further Reading

Additional notes: System Architecture Design Guidelines.

Review of model-view patterns:[Busc96, Fowl07, Gree07]

Model-view-controller: [Burb87, Busc96, Kras88]

Qt model-view: [Blan08] chap. 10


Improve this design of bus guide system

What’s fishy about this design?


References

J. Blanchette and M. Summerfield, C++ GUI Programming with Qt 4, 2nd ed., Prentice Hall, 2008.

S. Burbeck, Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC), 1987.

F. Buschmann et al., Pattern-Oriented Software Architecture: A System of Patterns, Wiley, 1996.

D. Greer, Interactive Application Architecture Patterns, 2007. M. Fowler, GUI Architectures, 2007. G. E. Krasner and S. T. Pope, A Cookbook for Using the Model-View-

Controller User Interface Paradigm in Smalltalk-80, SIGS, 1988.

Documents

System Architecturecs3249/lecture/system architecture.pdfstyle Architecture ... Extensibility Robustness ... Implemented in C, object-based but not object-oriented. has. CS3249 System