05-830, User Interface
Software, Spring, 1999
Lecture 7, February 17,
1999
Copyright © 1999 - Brad
Myers
Previous
Lecture . . .
Next Lecture
Software
Organization:
Lexical-Syntax-Semantics,
Seeheim
Model,
Model-View-Controller,
Object-Oriented Programming for UIs
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"
Conceptual-Semantic-Syntactic-Lexical-Pragmatic
- Derived from compiler theory and language work.
- Mostly relevant to older, non-DM interfaces
- Conceptual (definition from Foley & Van Dam
text, 1st edition)
- key application concepts that must be understood by user
- User model
- Objects and classes of objects
- Relationships among them
- Operations on them
- Example: text editor
- objects = characters, files, paragraphs
- relationships = files contain paragraphs contain chars
- operations = insert, delete, etc.
- 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
- 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
- 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.
- 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
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?
- Presentation Component
- External presentation of the user interface
- Generates the images
- Receives physical input events
- Lexical parsing
- Dialog Control
- 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.
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
- 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.
- Model
- Simple as an integer for a counter; string for an editor
- Complex as a molecular simulator
- Views
- Everything graphical
- Layout, subviews, composites
- Controller
- Interface between models, views, and input devices
- Schedule interactions with other VCs
- A menu is a controller
- 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
sub-controllers, models with sub-models...
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
Object-Oriented Techniques
- Note: Assume have had an introduction to 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.
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
- Create "instances" of the classes
- local copy of data
- may also be class data
- shares all methods
- "Inheritance": create a new class "like" the superclass
- 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
- 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")
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
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.
- 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.
Examples
- OO in SmallTalk
- First "pure" example
- Everything is an object (numbers, strings, etc.)
- Single inheritance
- Methods dispatched on a single parameter
- 3 + "4.5" different from "4.5" + 3
- Dynamic method lookup at run-time
- => "Message not understood"
- Strange syntax with special characters
- Whole environment (windows, browsers, MVC, etc.)
- 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
- 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
- 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++
- 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
- single inheritance
- "_" = new syntax: class_method(xxx)
- dynamic loading of object implementations
- querying an object's class at run-time
- Andrew consortium just finished converting to C++
- Motif
- just a set of conventions; no preprocessor
- not "real" inheritance, overriding
- Before C++ was popular, available
- Amulet provides a prototype-instance object system embedded
in C++
- Java is a object oriented language (more later)
Back to 05-830 main page