Lecture 9: Software Organization: LexicalSyntaxSemantics, Seeheim Model, MVC, ObjectOriented Program

1
Lecture 9Software Organization
Lexical-Syntax-Semantics, Seeheim Model,
MVC,Object-Oriented Programming for UIs

• Brad Myers
• 05-830Advanced User Interface Software

2
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

3
Conceptual-Semantic-Syntactic-Lexical-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

4
Conceptual-Semantic-Syntactic-Lexical-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.

5
Conceptual-Semantic-Syntactic-Lexical-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

6
Conceptual-Semantic-Syntactic-Lexical-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

7
Conceptual-Semantic-Syntactic-Lexical-Pragmatic,
cont.

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

8
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?

9
Seeheim Model

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

10
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

11
MVC
12
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.

13
MVC

• Model
• Simple as an integer for a counter string for an
  editor
• Complex as a molecular simulator
• Views
• Everything graphical
• Layout, subviews, composites
• Controller
• Schedule interactions with other VCs
• A menu is a controller

14
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 sub-controllers, models with sub-models...

15
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

16
Newer Models ofSoftwareOrganization

• Arch model
• 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), 3237. Jan, 1992 http//doi.acm.org/10.114
  5/142394.142401
• Adds abstract interface for the functional core
• Logical interaction layer widget libraries and
  user interface toolkits such as Motif or MFC.

17
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. 707719. http//citeseer.nj.nec.com/
  nigay91building.html, or http//iihm.imag.fr/pub
  ls/1991/
• Tries to integrate MVC with Arch
• Peter Tandlers Beach model
• For UbiComp covered later

18
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.

19
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

20
OO

• 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

21
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")

22
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

23
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.

24
Prototype-Instance model
25
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.

26
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
• 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.)

27
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

28
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

29
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

30
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
• 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
• Motif
• just a set of conventions no preprocessor
• not "real" inheritance, overriding
• Before C was popular, available

31
Examples of OO Systems

• Amulet provides a prototype-instance object
  system embedded in C
• Java
• C