home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0180.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  13.2 KB  |  299 lines
  1. Submitted-by: rcs@sei.cmu.edu (Robert Seacord)
  2.  
  3. the following article appears in the standards column of the october issue
  4. of ieee computer.  i am posting it to this newsgroup with permission from 
  5. the ieee.
  6.  
  7. rCs
  8. ______________________________________________________________
  9. User Interface Management Systems and Application Portability
  10.  
  11. by
  12.  
  13. Robert C. Seacord
  14. Member of the Technical Staff
  15. Software Engineering Institute
  16.  
  17.   Higher  level  programming  languages  and  standard  operating  systems now
  18. provide greater portability of application software than previously  possible.
  19. Software  developed  in  C  for  Unix,  for example, can be easily ported to a
  20. variety of different architectures and  machines.    Developing  language  and
  21. operating  system  standards  such  as  ANSI  C  and  IEEE  POSIX will further
  22. application portability.  At a quick glance it appears as though open  systems
  23. are finally becoming a reality, but are they really?
  24.  
  25.   As  porting  software  to  different  architectures  becomes more and more a
  26. matter of simply  recompiling  the  software  for  that  architecture,  it  is
  27. apparent  that  a serious problem in portability is with the user interface of
  28. these systems.  Now, more than ever, when a customer buys a computer  platform
  29. they  are  also  buying  a  "look and feel" associated with that system.  When
  30. using an Apple Macintosh, for example, the user expects to be able to  perform
  31. a variety of actions using a single button mouse.  When working with an MS DOS
  32. application, the user expects to be able to perform the same actions using the
  33. keyboard.    When  running  OpenLook,  Motif, or NeXTStep the user expects the
  34. application to provide a defined look and feel.   Porting  an  application  to
  35. simply run on a different platform is insufficient; there is a requirement for
  36. the application interface to behave in a similar fashion to other applications
  37. developed for that environment.
  38.  
  39.   Software  designs are usually not extensible enough to allow the integration
  40. of different user interface toolkits, particularly if  these  toolkits  employ
  41. significantly  different  models  in  their  application interfaces.  Changing
  42. toolkits or integrating new toolkits usually requires  major  modification  to
  43. the application, which then requires extensive re-testing of the application.
  44.  
  45.   Current  standards  activities are just beginning to address these problems.
  46. To date, standards bodies have attempted to define an abstract user  interface
  47. toolkit  that  can  be  implemented  in  different  ways.  Where this approach
  48. provides some degree of device independence it does not allow for the  removal
  49. of  stylistic  concerns  from  the  application.   For example, where one user
  50. interface style guide may call for a pull-down menu, another may  call  for  a
  51. command line interface.
  52.  
  53.   One  approach  for  addressing the problem of application portability across
  54. multiple look and feel platforms is the definition  and  implementation  of  a
  55. method  for  separating  the  application  from  the  user  interface.    This
  56. separation makes changing the user interface of the system practical. It  also
  57. makes  it  possible  to  change  user interface toolkits without modifying the
  58. application software.
  59.  
  60. User Interface Management Systems
  61.  
  62.   The term user interface management system (UIMS) was first coined at a  1982
  63. Workshop  on  Graphical  Input  Interaction Technique (GIIT) [17].  UIMSs are,
  64. among other things, intended to encourage the separation of a software  system
  65. into  an  application  portion  and a user interface portion.  The application
  66. portion of  a  system  implements  the  core  functionality,  while  the  user
  67. interface portion implements the user interface dialogue.
  68.  
  69.   UIMSs   provide   facilities   for   defining   both  presentation  and  the
  70. computer-human dialogue components of a user  interface.    A  UIMS  also  may
  71. provide  facilities to support prototyping, encourage a design that allows for
  72. easy  modification  of  the  user  interface,   support   implementation   and
  73. maintenance   of   the   user   interface,  and  allow  for  the  evolutionary
  74. incorporation of new user interface technologies.
  75.  
  76.   Most UIMSs are based on the Seeheim architecture [7] (see Figure 1).    This
  77. architecture  uses a layered approach similar to the one used in International
  78. Standards Organization (ISO) Open Systems Interconnection (OSI) standard.  The
  79. architecture  is intended to encourage the separation of functionality between
  80. the application and the user interface portions of a  software  system.    The
  81. three different layers of the architecture provide differing levels of control
  82. over user input and system output.
  83.  
  84.         Application Layer
  85.  
  86.         Dialogue Layer
  87.  
  88.         Presentation Layer
  89.  
  90.                         Figure 1:   UIMS Architecture
  91.  
  92.   The application layer consists of the core functionality of the  application
  93. that can be described in a presentation independent manner.  For example, in a
  94. calculator program this would include the underlying math subroutines library.
  95.  
  96.   The dialogue layer  specifies  the  presentation  dependent  portion  of  an
  97. application  system including the dynamic behavior of the user interface.  The
  98. dialogue should allow the display and removal of interaction  objects  without
  99. application  involvement and support cascading menus, direct manipulation, and
  100. other user interface sytles and techniques.  The dialogue provides the mapping
  101. between  the presentation and application layers.  The user interface dialogue
  102. may be specified using a user interface definition language (UIDL)  or  by  an
  103. interactive technique.
  104.  
  105.   The  presentation  layer  controls  the  end-user interactions and generates
  106. low-level feedback.  The  presentation  layer  consists  of  a  collection  of
  107. interaction objects defined for a given user interface technology.
  108.  
  109. Existing Approaches
  110.  
  111.   Since  the  1982 GIIT Workshop, there have been a number of efforts to build
  112. UIMSs that achieve the goal of  separation  of  concerns,  while  remaining  a
  113. practical   approach  to  software  development.    These  systems  have  been
  114. classified by the model used in dialogue specification.    Some  of  the  more
  115. successful  approaches have been:  event-driven, declarative, object-oriented,
  116. data-driven, and interactive layout systems.
  117.  
  118.   In the event-driven approach, inputs are  considered  as  events  which  are
  119. immediately  handled  by  event  handlers.    Event  handlers can cause output
  120. events, change  the  internal  state  of  the  system,  and  call  application
  121. routines.   Examples of event-driven systems include the University of Alberta
  122. UIMS [6], ALGAE [5], Sassafras [9], and the TeleUSE UIMS [16].
  123.  
  124.   Another approach is the use of declarative languages  in  which  constraints
  125. are  defined in order to specify what the system should do rather than specify
  126. how it should be done.  An example of a system that  takes  this  approach  is
  127. Cousin [8].  In this category, there is a class of systems which automatically
  128. generate the user interface based on a definition  of  the  semantic  commands
  129. supported by the application. Examples are the UofA* UIMS [12] and MIKE [10].
  130.  
  131.   An  object-oriented  approach  uses  objects for defining user interactions,
  132. transforming data and interacting with the application.  A good example  of  a
  133. commercially  available  system  that uses an object-oriented approach is Open
  134. Dialogue [1] developed by Apollo Computer.
  135.  
  136.   In the data-driven approach, the application communicates with the  UIMS  in
  137. terms  of  shared  data elements.  The UIMS behaves like an active database in
  138. that it provides a mapping between application data and user interface toolkit
  139. objects, and notifies the application of changes to application data resulting
  140. from user interactions.  This approach was implemented  in  the  Serpent  UIMS
  141.  [2]  developed  at  the  Software  Engineering  Institute  at Carnegie Mellon
  142. University and the George Washington UIMS [11].
  143.  
  144.   Interactive layout systems allow the user to build user interface by  direct
  145. manipulation.    Examples are Menulay [3], DialogEditor [4], vu [13], and TAE+
  146.  [15].
  147.  
  148. UIMS Study Group
  149.  
  150.   The IEEE P1201 working group was formed in January of 1989 and chartered  to
  151. develop standards that would further application and user portability in the X
  152. Windows Environment [14].  Since P1201 was formed,  Open  Software  Foundation
  153. (OSF), Sun and AT&T have independently developed toolkits for X Windows.  Much
  154. of the P1201 effort has been spent trying to decide if any of  these  toolkits
  155. can  serve as a basis for a standard or if a "virtual" toolkit approach can be
  156. used.
  157.  
  158.   In August of 1989, a UIMS study group was begun in  P1201  to  determine  if
  159. UIMS  technology was sufficiently advanced to solve the problem of application
  160. portability across multiple look and feel platforms and to define the scope of
  161. a UIMS standard.
  162.  
  163.   The   group   identified  two  components  where  standardization  would  be
  164. beneficial to the industry.  The first of these is an application  programmers
  165. interface (API) that would:
  166.  
  167.    1. Provide a standard application programmers interface across changes
  168.       in the underlying toolkit.
  169.  
  170.    2. Support  the  separation  of  an  application   into   presentation
  171.       independent  and presentation dependent layers corresponding to the
  172.       application, dialogue,  and  presentation  layers  of  the  Seeheim
  173.       architecture.
  174.  
  175.    3. Allow   the  development  of  applications  that  are  presentation
  176.       independent  (i.e.,  the  underlying  windowing  system   or   user
  177.       interface toolkit).
  178.  
  179.   The  second  component is a UIMS interchange format (UIF).  The purpose of a
  180. standard UIF is:
  181.  
  182.    1. To enable a wide variety of UIMSs to use a single format  to  store
  183.       and exchange their data.
  184.  
  185.    2. To  allow  vendors  to develop compilers or interpreters that could
  186.       "execute" the UIF on their  platforms  in  a  manner  analogous  to
  187.       postscript printers.
  188.  
  189.   The  P1201  UIMS  study  group  has  evaluated  a  number  of user interface
  190. management systems including Serpent, TeleUSE, and TAE+.  The concensus of the
  191. group  is that the state of the practice is sufficiently advanced to warrant a
  192. standards effort.  It is believed that a  UIMS  standard  would  enhance  both
  193. application  portability  and  the  state  of  the  practice in user interface
  194. development.
  195.  
  196.                                   REFERENCES
  197.  
  198.  
  199. [1]   Apollo Inc.
  200.       Open Dialogue:  Designing Portable, Extensible User Interfaces.
  201.       1987
  202.  
  203.  
  204. [2]   Bass, L.J., et al.
  205.       Serpent:  A User Interface Environment.
  206.       In Proceedings, Winter 1990 USENIX Technical Conference.  Washington,
  207.          D.C., January, 1990.
  208.  
  209.  
  210. [3]   Buxton, W., Lamb, M.R., Sherman D., Smith, K.C.
  211.       Towards a Comprehensive User Interface Management System.
  212.       In Computer Graphics: SIGGRAPH'83 Conference Proceedings, pages 35-42.
  213.          Detroit, MI., July, 1987.
  214.  
  215.  
  216. [4]   Cardelli, L.
  217.       Building User Interfaces By Direct Manipulation.
  218.       In Proceedings, ACM SIGGRAPH Symposium on User Interface Software, pages
  219.          152-166.  ACM, New York, NY, 1988.
  220.  
  221.  
  222. [5]   Flecchia, M.A. and Bergeron, R.D.
  223.       Specifying Complex Dialogs in ALGAE.
  224.       In Proceedings SIGCHI+GI'87: Human Factors in Computing Systems, pages
  225.          229-234.  Toronto, Ont., Canada, April, 1987.
  226.  
  227.  
  228. [6]   Green, M.
  229.       A Survey of Three Dialogue Models.
  230.       ACM Transactions on Graphics 5(3):244-275, July, 1986.
  231.  
  232.  
  233. [7]   Green, M.
  234.       Report on Dialogue Specification Tools.
  235.       User Interface Management Systems :9-20, 1985.
  236.  
  237.  
  238. [8]   Hayes, P.J., Szekely, P.A., Lerner, R.A.
  239.       Design Alternatives for User Interface Management Systems Based on
  240.          Experience with COUSIN.
  241.       In Proceedings SIGCHI'85: Human Factors in Computing Systems, pages
  242.          169-175.  San Francisco, CA, April, 1985.
  243.  
  244.  
  245. [9]   Hill, R.D.
  246.       Event-Response Systems -- A Technique for Specifying Multi-Threaded
  247.          Dialogues.
  248.       In Proceedings SIGCHI+GI'87: Human Factors in Computing Systems, pages
  249.          241-248.  Toronto, Ont., Canada, April, 1987.
  250.  
  251.  
  252. [10]  Olsen, D.R.
  253.       The Menu Interaction Kontrol Environment.
  254.       ACM Transactions on Graphics 5(3):318-344, 1986.
  255.  
  256.  
  257. [11]  Sibert, J.L.
  258.       An Object-Oriented User Interface Management System.
  259.       In Computer Graphics: SIGGRAPH'86 Conference Proceedings, pages 259-268.
  260.          Dallas, Texas, August, 1986.
  261.  
  262.  
  263. [12]  Singh, G. and Green. M.
  264.       A High Level User Interface Management System.
  265.       In Proceedings SIGCHI'89:  Human Factors in Computing Systems, pages
  266.          133-138.  ACM, New York, NY, 1989.
  267.  
  268.  
  269. [13]  Singh, G. and Green. M.
  270.       Designing the Interface Designer's Interface.
  271.       In Proceedings, ACM SIGGRAPH Symposium on User Interface Software, pages
  272.          109-116.  ACM, New York, NY, 1988.
  273.  
  274.  
  275. [14]  Mehta, S.
  276.       User Interfaces and the IEEE P1201 Committee.
  277.       Unix Review 8(1):14-20, January, 1990.
  278.  
  279.  
  280. [15]  Szczur, L. and Miller, P.
  281.       Transportable Applications Enviroment (TAE)+:  Experiences in
  282.          Objectively Modernizing a User Interface Environment.
  283.       In OOPSLA'88 Conference Proceedings, pages 58-70.  San Diego, CA,
  284.          November, 1988.
  285.  
  286.  
  287. [16]  TeleLOGIC.
  288.       TeleUSE Reference Manual.
  289.       1989
  290.  
  291.  
  292. [17]  Thomas, J.J. and Hamlin, G.
  293.       Graphical Input Interaction Technique (GIIT) Workshop Summary.
  294.       Computer Graphics 17(1):5-30, January, 1983.
  295.  
  296.  
  297. Volume-Number: Volume 21, Number 179
  298.  
  299.