Object Level Architecture Have a lot of different

Object Level Architecture

Have a lot of different parts of a UI n Need aspects to go together – work together as a whole – integrated for UI reasons – need to mix at the object level Fdelegate specifics of input, output, layout, etc to each object • natural / only place to do it 2

Separation of concerns n But, need to keep all this separate stuff from getting tangled up – important SE reasons to do this – “separation of concerns” n How do we get all this into one object and not incur complexity? 3

Approaches to separation of concerns n Three general approaches – several models in each – not mutually exclusive Fcan / should use multiple Composition n Inheritance n Aggregation n 4

Composition n Put together interactive objects at larger scale than interactors – container objects – e. g. , boxes & glue layout objects – containers can also add input & output behavior to things they contain Fe. g. , sub. Arctic drag_container & shadow_drag_container 5

Composition (containers) n n Can also have more sophisticated containers that change input/output Composition approach separates concerns into different interactors 6

Approaches at the interactor level n Inheritance – all concerns in one object – inherit / override them separately – works best with multiple inheritance – example: draggable_icon Finherit appearance from “icon” • output aspects only Finherit behavior from “draggable” • input aspects only 7

Inheritance n Don’t have multiple inheritance in most languages (i. e. java) – but can still (partially) take this approach – sub. Arctic does this n Inheritance tends to give tighter coupling between aspects – together in the code, no boundaries 8

Another object level approach: Aggregation Actually separate out different concerns into separate objects n Classic architecture: “model-view-controller” (MVC) n – from Smalltalk 80 9

Model-View-Controller n Each is separate object Output View Model Input Controller 10

Model-View-Controller n Model – the “underlying” or “application” information we interact with – MVC takes approach of “editing” this information – Fits with direct manipulation interface paradigm (model is object user manipulates, but not representation) 11

Model-View-Controller n Model – Simple examples Ftext editor: model is text string Fslider: model is an integer n Model is “data only” – no input or output aspects – but may include behavior (semantics) 12

Model-View-Controller n View – mechanism needed to map model data to rendition (view / display) – all output aspects here – when model changes, view object is informed – view arranges to update screen 13

Model-View-Controller n Controller – listens to user input – translates into changes to model – all input aspects here n Controller almost always has to “talk to” view – Why? 14

Model-View-Controller n Controller almost always has to “talk to” view – need geometry of output to interpret input (e. g. , picking) – need to do feedback! n As a result, VC tend to be very tightly coupled 15

Model-View-Controller n In theory should be able to plug different views and controllers – good property – in practice VC tend to be written together and be too tightly coupled n Typical modern view of MVC – combine VC into one object 16

Another architectural example: The sub. Arctic input architecture n SA takes a (primarily) inheritance based approach – all n tasks in one object (interactor) But, splits part of functionality out and moves it “up” into toolkit – reusable by all (but still pluggable) 17

Three classes of toolkit “users” (programmers) n Toolkit author – work n is done only once Interactor programmer – writes n new interactor classes End programmer – just uses existing library 18

sub. Arctic goals – Toolkit author – Interactor programmer – End programmer n Move work To make creating interactors easy we “factor out” work and push it up into the toolkit – infrastructure & base classes – particularly work of handling input 19

Input handling in sub. Arctic n n See very similar FSM controllers over and over SA pulls these out of objects and allows them to be reused – implemented in toolkit once 20

Input handling in sub. Arctic n simple_press_draggable – drag_start() – drag_feedback() – drag_end() n System keeps state & does common work – calls objects at right points – provides relevant information 21

Input handling in sub. Arctic n Mechanism for reuse is very simple – just n implement an interface All of event dispatch infrastructure and much of detailed control now in toolkit – much easier (just pick from library) 22

How this works n Recall: two major ways to dispatch inputs – positional & focus These are policies for dispatch n SA impl as “input policy” objects n – objects that implement a particular method of delivery 23

SA input policy objects n Example: positional – implements pick to find all objects “under” the event – does delivery based on pick list n Other special purpose policies – modal dialog policy – “monitor” policies n Policies are in a (prioritized) list – you can add more! 24

SA input policy objects n Each policy maintains a set of “dispatch agents” – responsible for dispatching a particular kind of input Fe. g. , press, click, and double-click Fvarious kinds of dragging Fkeyboard input – each implements canonical FSM 25

Dispatch agents n Each policy’s agents are in an extensible list – new ones can be (and are) added to meet needs of individual interfaces – can do small changes, enhancement by subclassing existing agent n Overall, very extensible 26

How it all goes together Events Focus Policy Positional Policy Etc… Text Press Etc. . . Move drag Click Grow drag Rollover Etc. . . 27

Another related approach n Myers’ “Interactor” model – Note name conflict – also “factors out” input aspects – this time using aggregation approach Feach interactive object consists of an “interactor” object (just input) and output object (M+V) 28

Myers’ Interactor model n Instead of N different FSM controller (SA dispatch agents), provides one generic FSM – highly parameterized – FSM gets used in 6 interactor types that cover almost all interactions 29

(Myers’) interactor objects Each interactor parameterized by: – Output object(s) – Start-where & Running-where regions – Start, stop and abort event desc – Actions – (other minor stuff we will ignore) 30

(Myers’) interactor objects Each interactor parameterized by: – Output object(s) Fresponsible for creating and maintaining appearance Fmaintains most of “state” or application interface Froughly model + view 31

(Myers’) interactor objects Each interactor parameterized by: – Start-where region Fregion where interaction starts – Running-where region Fregion interaction must stay in – Start, stop and abort event desc 32

(Myers’) interactor objects Each interactor parameterized by: – Feedback objects Fprovide feedback part of output Fcan be the output object itself (e. g. , drag the object) Fcan be “low detail representation” – Interim feedback and Final feedback objects 33

(Myers’) interactor objects Each interactor parameterized by: – Actions FStart, Stop (= done), Abort, Outside, Back-inside • Pieces of code to be executed • Feedback objects 34

(Myers’) interactor objects n More parameters control specifics of how interactor acts on feedback and output objects – final version had 34 parameters! (hints at the drawbacks of this) 35

Simplified version of the FSM Stop-Event Stop-Action Running-Action Start-Event over Not over Start-Where running-where Running Start-Action Outside Over running-where Stop-Event Stop-Action Back-Inside-Action 36

Full version of FSM Stop-Event If option = Abort then Abort-Action else Stop-Action Start Running Abort-Event Abort-Action Outside 37

Six interactor types use this FSM n Differ in how the manipulate output and feedback objects – Menu – Move-grow – New-point – Angle – Text – Trace 38

Six interactor types use this FSM n Menu – choosing n Move-grow – changing n from a set of items size/position of object New-point – enter information defined by one or more points Fe. g. , line, rectangle, polygon 39

Six interactor types use this FSM n Angle – enter n angle about some point Text – single and multi-line text entry/edit – this doesn’t really fit well n Trace – stroke or path on the screen 40

Recap n Both SA and Myers’ interactor model separate out input part – typically the hard part and provide specialized and reusable support n Myers’ uses aggregation n SA uses inheritance (+ objects in toolkit infrastructure) 41

42