05-830, User Interface Software, Spring, 1997
Lecture 7,   February  19, 1997
Copyright © 1997 - Brad Myers

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
  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
    • 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