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

1. Lecture 7:Software 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), 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.

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

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#