Lecture 7:
Software Organization: Lexical-SyntaxSemantics, Seeheim Model, MVC,
Object-Oriented Programming for UIs
Brad Myers
05-830
Advanced User Interface Software
1
Software Organizations




Ways to organize code, rather than tools.
"Models"
Helps think about modularization and
organization.
Goal: separation of UI and rest of software =
“semantics”
2
Conceptual-Semantic-SyntacticLexical-Pragmatic



Derived from compiler theory and language
work.
Mostly relevant to older, non-DM interfaces
Pragmatic (as subdivided by Buxton)





How the physical input devices work
required "gestures" to make the input.
Ergonomics
skilled performance: "muscle memory"
press down and hold, vs. click-click
3
Conceptual-Semantic-SyntacticLexical-Pragmatic, cont.

Lexical (as subdivided by Buxton)

spelling and composition of tokens




“add” vs. “append” vs. “^a” vs.
Where items are placed on the display
“Key-stroke” level analysis
For input, is the design of the interaction
techniques:

how mouse and keyboard combined into menu,
button, string, pick, etc.
4
Conceptual-Semantic-SyntacticLexical-Pragmatic, cont.

Syntactic


sequence of inputs and outputs.
For input, the sequence may be represented as
a grammar:



rules for combining tokens into a legal sentence
For output, includes spatial and temporal factors
Example: prefix vs. postfix
5
Conceptual-Semantic-SyntacticLexical-Pragmatic, cont.

Semantic




functionality of the system; what can be
expressed
What information is needed for each operation
on object
What errors can occur
Semantic vs. UI is key issue in UI tools


but "semantic" is different than meaning in compilers
"Semantic Feedback“


Depends on meaning of items
Example: only appropriate items highlight during drag
6
Conceptual-Semantic-SyntacticLexical-Pragmatic, cont.

Conceptual (definition from Foley & Van Dam
text, 1st edition)


key application concepts that must be understood
by user
User model
1.Objects and classes of objects
2.Relationships among them
3.Operations on them
 Example: text editor
 objects = characters, files, paragraphs
 relationships = files contain paragraphs contain
chars
7
 operations = insert, delete, etc.
Seeheim Model


Resulted from the 1st UI software tools workshop which
took place in Seeheim, Germany. Nov 1-3, 1983.
Logical model of a UIMS


UIMS = User Interface Management System (old name for user
interface software)
All UI software must support these components, but are they
separated? How interface?
8
Seeheim Model

Presentation Component





Dialog Control



External presentation of the user interface
Generates the images
Receives physical input events
Lexical parsing
Parsing of tokens into syntax
Must maintain state to deal with parsing; modes.
Application Interface Model




defines interface between UIMS and the rest of the software
"Semantic feedback" for checking validity of inputs
Not explicit in UIMSs; fuzzy concept.
Roughly like today's call-backs.
9
Model-View-Controller





Invented in Smalltalk, about 1980
Idea: separate out presentation (View), user input
handling (Controller) and "semantics" (Model)
which does the work
Fairly straightforward in principal, hard to carry
through
Never adequately explained (one article, hard to
find)
Goals


program a new model, and then re-use existing views
and controllers
multiple, different kinds of views on same model
10
MVC
11
MVC


Views closely associated with controllers.
Each VC has one M; one M can have many
VCs.


VCs know about their model explicitly, but M
doesn't know about views
Changes in models broadcast to all "dependents"
of a model using a standard protocol.
12
MVC

Model



Views



Simple as an integer for a counter; string for an editor
Complex as a molecular simulator
Everything graphical
Layout, subviews, composites
Controller


Schedule interactions with other VCs
A menu is a controller
13
MVC

Standard interaction cycle:



User operates input device, controller notifies model to
change, model broadcasts change notification to its
dependent views, views update the screen.
Views can query the model
Problems:



Views and controllers tightly coupled
What is in each part?
Complexities with views with parts, controllers with subcontrollers, models with sub-models...
14
Model-View



Since hard to separate view and controller
Used by Andrew, InterViews
Primary goal: support multiple views of same
data.


Simply switch views and see data differently
Put into Model "part that needs to be saved
to a file"

but really need to save parts of the view
15
Newer Models of
Software
Organization

“Arch” model



dialogue
logical
interaction
functional
core adapter
physical
interaction
functional
core
Bass, R. Faneuf, R. Little, N. Mayer, B. Pellegrino, S.
Reed, R. Seacord, S. Sheppard, and M. Szczur, 1992. “A
metamodel for the runtime architecture of an interactive
system: the UIMS tool developers workshop”, ACM
SIGCHI Bulletin. 24 (1), 32–37. Jan, 1992
http://doi.acm.org/10.1145/142394.142401
Adds abstract interface for the functional core
Logical interaction layer: widget libraries and user
interface toolkits such as Motif or MFC.
16
Newer Models of Software
Organization

PAC-Amodeus

Nigay, L. and Coutaz, J., 1991. Building User
Interfaces: Organizing Software Agents. In:
ESPRIT'91, Project Nr. 3066: AMODEUS
(Assimilating Models of DEsigners, Users and
Systems), pp. 707–719.


http://citeseer.nj.nec.com/nigay91building.html, or
http://iihm.imag.fr/publs/1991/
Tries to integrate MVC with Arch
Peter Tandler’s Beach model

For UbiComp – covered later
17
Object-Oriented Techniques

Motivation


Became popular along with GUIs, Direct
Manipulation
Icons, graphics seem like objects:


have internal state, persistance
OO was originally developed (SmallTalk) and
became popular (C++) mostly due to GUIs.
18
Object Oriented

As a UI technique:






Same as GUI, Direct Manipulation = icons, graphical
objects, widgets
Here, as a programming paradigm (often in a
language)
A form of "data abstraction"
"Classes" describe the basic structure of the data
Also, the methods that can be called
Usually no direct access to the data, only the
methods
19
OO

Create "instances" of the classes




"Inheritance": create a new class "like" the
superclass



local copy of data
may also be class data
shares all methods
by default has all the same methods and data
can add new data and methods and re-program inherited
methods
Example: graphical_object.draw ... circle.draw
20
OO

New style of programming; thinking about the
problem


Many books about how to do it right.
OO design; getting the classes and protocols right





So subclasses don't have extra, wasted data space
Methods make sense to all sub-classes
So external classes don't need to know inside description.
Also OO databases, etc.
Implementation:


object in memory, starts with pointer to table of
methods, etc.
lots of tricks and extra declarations in C++ etc. to avoid
overhead of lookups ("virtual", "pure virtual")
21
Multiple inheritance






Class has multiple parent classes
Combine all the methods and data of all
Special rules for when conflict (same method, same
name of data with different types, etc.)
Example: circle inherits from graphical-object and
moveable-object
Complex so often not used even when available
Amulet uses constraints to provide flexible copying
of values instead
22
Prototype-Instance model



Instead of the class-instance model
All objects are instances
Can use any object as a prototype for other objects





Inherits all slots it doesn't override (= instance variables,
member variables, fields, attributes).
Methods are just a value in a slot
Dynamic changing of methods
Easy to implement using structures.
Usually, changing prototype data also changes all
instances that do not override it.
23
Prototype-Instance model
24
Prototype-Instance model



May provide adding and removing of slots
dynamically to any instance
Simpler model, easy to implement
But much less efficient




Can't usually compile slot accesses into structure
access; may need a search
Type checking on slots
Methods looked up at run-time
Space for names of slots, extra pointers, etc.
25
Examples of OO Systems

OO in SmallTalk




First "pure" example
Everything is an object (numbers, strings, etc.)
Single inheritance
Methods dispatched on a single parameter


Dynamic method lookup at run-time



3 + "4.5" different from "4.5" + 3
=> "Message not understood"
Strange syntax with special characters
Whole environment (windows, browsers, MVC, etc.)
26
Examples of OO Systems

OO in C++





Numbers, strings, etc. not objects
Lots of mess to make it fit with C
Statically (compile-time) determine types,
methods
Originally a pre-processor (new syntax)
Multiple-inheritance
27
Examples of OO Systems

OO in CLOS (Common-Lisp Object System)




Add-on to language
Special feature: method dispatch on all
parameters
+(int int) +(int str) +(str int) +(str str)
Methods not as tightly coupled with objects
28
Examples of OO Systems

OO in MacApp




Because OO so natural for UIs, invented their
own language: Object Pascal with help from
Werth
Used in MacApp
SmallTalk model, but more compile-time
checkable
Eventually abandoned in favor of C++
29
Examples of OO Systems

OO in Andrew and Motif




Invented their own object systems in C
"Intrinsics"
Mainly is a method and inheritance protocol
Andrew: (ATK) pre-processor for header files







Motif



single inheritance
"_" = new syntax: class_method(xxx)
dynamic loading of object implementations
querying an object's class at run-time
Andrew converted to C++
Now defunct
just a set of conventions; no preprocessor
not "real" inheritance, overriding
Before C++ was popular, available
30
Examples of OO Systems



Amulet provides a prototype-instance object
system embedded in C++
Java
C#
31