ented specification to object-oriented im- plementation. It is essentially a task-ori- ented specification scheme based on a semantic network. For each element ...
uesigning Maintainable, Reusable Interfaces RAIMUND K. EGEand CHRISTIAN STARY Florida International University
relationships in the interface speczJicntion and explicitly representing constraints, designe n can meate interfaces that meet the ofien elusive user requirements.
tance. Task-oriented interface specification in which the task relationships, not just the task itself, are captured is an effective way to represent user requirements, but there are few strategies to implement it. Conversely, a modular, object-oriented implementation suffers from insufficient modeling and specification strategies. Thus, the ideal approach would provide the modeling ease of object-oriented implementation while preserving task relationships and explicitlyrepresenting them as constraints.The conceptual framework we propose lets you capture the essential structure of any interface from task-oriented specificationto object-oriented implementation. It is essentially a task-oriented specification scheme based on a semantic network. For each element, as
well as for the complete network, there is a direct representation suitable for objectoriented implementation. As part of our work, we also developed an extension to the traditional object-oriented model, which preserves the explicit representation of relationships as constraints. When task relationshps are covered by objects that model constraints, design and implementation strategies become more conceptually uniform. T h e entire interface-development process is more flexible and productive. Perhaps the greatest benefit is the increased potential of reusing interface components.
WHY A COMBINED APPROACH?
In most computer applications, users do not want to be t h " g about how computer parts interact, so the interface
l I
must be as transparent as possible. ,\,laking it that way is not tritial for two reasons. First, for users to accept the interface, it must let them accomplish tasks in the most straightionvard way possible and still meet the entire range of problen-solving requirements. Plus, i t must not require them to perform sophisticated, unrelated operatio~isthat deal with the specifics of interfiace design or implementation. Consequently, the designer must thoroughly understand the complexity of the user’s tasks - soniething that rarely occurs. More often than not, a set of elementary system functions is always bisible to the user, which de-
Task orientation abne. T h e lack of re- usually follou- the Sccheiin interface search in implementing task-oriented model which divides any interface into a I1 specification has resulted in a lack of triple comprising presentation, dialogue 11 knowledge about how to identify the con- control, ami problen-data Ixaiiageiiicnt tent of each interface component and how (application).’ Hence, large interfaces, to keep coniponent functions separate. which are geiierally composed of coinpoT h e knowledge needed for dialogue con- nents from the tool kit’s library, iniist be trol is vel?; complex in such an implemen- constructed from a nuniber oftriples, each 1 tation and is intermixed with application of which has its o \ v n dialogue-control 1’ and presentation aspects. component to coordinate the presenta.-\variety of identification techniques tion and application components. Any ‘i have been proposed - algebra, formal component of ;itriple may also he part of grammar, finite-state niachines, and decli- another triple, and several triples can share I’ cared software-engineer- application components. Figure 1 show-sthc triples (f)l, C1, A ) I ’ ing methods like statetransition diagrams’ - and (I?, C2, ,4’). Each triple implements 1 hut for the Inost part, deI1
-
~
The key to getting
system perspective.
+ he much more explicit in representmg user tasks aiid their orgaiuzatlon, + more accurateli model the data in
m d procedures) E’oi-nial gi ‘imiiiar h a s s i m i l a r prot)lenis, incluciing the talui e to model paiaciilx dialopes accuratel\
through mndou s, menus, or a mouse, + relate interamon rnedia to the dat‘i
iriing productlwg tor niodern Interfaces because it clearl! dc~omposescoiiipoiient
usefi’ u orl,en\ ironment, not just indicid-
hehaiioial elements I n a modular U a that
all the components ofall the mterfsces a system.
Object-oriented modehng lets you
goxlped mto classes In a class herarchy, objects of superior classes proper-
nents can be speciahzedor extended
I
I
Figure I . Linking iiitnface cumponmnts. Each component isrepresmtedirsa triple, in which Crepresents dialogue control, P repepl-esentspresentation, and A repmenu- application. Problem arise because traditional object-irriented models provide 120 way t o keep partr of the mple sepcrrate.
one aspect of a larger interface, and they shareanapplicationcomponent(A and A’ denote the same set of application objects). Since the dialog component CI controls A in the context of (PI, C1. A). ,, anv , chame that occurs within thiy triple is not reflected by ( E , A). Moreover, ci and C2 can initiate a change t o A simultaneously. Therefore, CI and C2 must negotiate access to A. In effect, ~2 does not control A; it controls A’. To connect these triples correctly, both dialogue components must communicate, which they can do only through message (procedure-call) passing. Normally, communication through message passing is considered an advantage of object orientation, but here, it becomes a liability. Components connected in such a way must follow a precise protocol (sequence)in sendingand receiving messages or the context will be lost. Addmg thls much detail makes it hard to use components from an interface tool kit’s library, whch limits the productivity possible with a traditional object-oriented interface design.
Dedaringconstraints. Because object-orientation alone does not let you capture the relationships among interface components, we propose addmg constraint specification. A constraint, such as a = b + c, differs from an imperative assignment statement because it is a declarative specification of a state; it does not restrict how that state is reached. Whenever a, b, or c changes, the constraint is resatisfied. By using declarative techtuques - actually declaring component relationshps as part of the object-oriented model - you can effectively Mc library components into triples to form an interface. In the Figure 1 example, a declarative specification night be phrased as P1 ==A for the triple (Pl,Cl ,A),where == denotes a constraint. That is, presentation P1 reflects application A, and vice versa, in all cases. Now, if thls triple is lmked with P2 ==A,it yields a combined interface component P1 == A == P2, in which P1 (a presentation) is constrained to reflect A (the application), which is then constrained to reflect P2 (another presentation); hkewise. P2 is constrained to reflect A, which is constrained to reflect P1. The composition yields a complete interface component without additional cornmunication. Any triples become connectable without each knowing in advance in what context they will be used. Constraints can be applied at all levels of interface development. For example, suppose you wish to join two subwindows at one edge. If the user repositionsone subwindow,she expects the adjacent subwindow to be repositioned also (presening the fact that they are joined). Without constraints, the designer would have to consider the adjacent window explicitly when specifymg the “move” subtask. However, if the joining is stated as a Constraint by the designer, the implementation provides a way to satisfy the constraint, he does not have to consider the adjacent window, and the design becomes much easier.
-
I
a,
26
r
--
The ~nteraction Management Network uses task-oriented specification to offset weaknesses in obiect-oriented implementation.
Constraints can be satisfied by local propagation, in which local informationis used to maintain a constraint; by transformations, in which constraint graphs are considered globally; and by relaxation, in whch sets of constraints are evaluated iteratively. Typically, a constraint-satisfaction algorithmcombines these three techniques accordmg to the complexity of the constraints involved. Another major advantage of declaring constraints is that you can maintain component relationshps automatically. S s tems such as T h g L a b , FilterBrowser, X
Y-
Window System’s RTL Window Manager, Smalltalk-80’s Constraint Window System: and Jade are all based on the use of constraints. The Task Interaction and Control System, developed by Mark Grossman and Constraint Logic Programming, uses logic as a basis for specification and logic programming as a basis for automatically maintaining constraints. These systems use predicates - equal(a,plus(b,c)) - to express a = b + c. The advantage is that you can maintain constraints with automatic theorem provers &e Prolog.
INTERACTIONMANAGEMENT NETWORK Our banework, called the Interaction Management Network, helps compensate for weaknesses in object-oriented implementation by adding task-oriented specification to achieve + high-level m o d e h g support, + modular development, + encapsulation throughout development and implementation,and + reusable interface components, as well as a constraint-based, object-oriented paradigm for interface specification. T h s paradigm has proved useful in representing and r e h n g tasks and in promoting modular, declarative interface components.5,6 Because users, system analysts, designers, and programmers use IMN,it must represent several categories of specification knowledge, including user tasks, problem domain, interaction-media domain, and elementary system functions. All user-specified tasks are mapped to
NOVEMBER 1992
nodes of a semantic network to provide a iuiified specification of the application’s tasks, task analysis, desicgn, and implementation. I,\!lN comprises subjects of work (docunients and so on). tasks aid subtasks. and task and subtask impping to elementar?. procedure calls, such as opening a window or editing a document. Its tmilding blocks are temis, relationships, vertical decoiiiposition, and horizontal deconiposition.
~
prol)lenis domain. Such media night include pointing delices to handle windows that contin documents, for exainple. Finally, the designer maps the task description from the prexious two levels to svsteni functions. As tasks are broken into sulmsks, constraints such as “lxfore,” arise, which are required for d4imnic data and interaction-media handling.
designer then relates the problem domain to the interaction domain, which is horizontal decomposi tion.
Vertical decomposition. T o handle t h e translation 6-om elo1)al activities (which correspond to iiscr tasks) to system fiinctions, LMN has three layers (top down): global activities, prot)lem-domain data and interaction media (window, docuRelationships. Regardless of the almrac- ment, and so on), and system functions tion level - user tasks, that handle problem-doTemts. Tei-11~ express the users’ knou-l- prol~lenidomain, intermain data ?like O p e n edge according to work emironment and action - i n e d i a domain , Transaction for transac,. level of experience. T h e y represent and Systeln functions tion management) and procedures that handle knowledge in four categories, as shown in terms can lie correlated. ’l‘hc semantics of relainteraction media (like Table 1. At the highest level arc user tasks, in tionships are exlxessed ;is Open L2’indow for winwhich users describe their tasks as they links in the semantic netdow management). ~ v o u ~exIlect c ~ the application to s l l p ~ ~ O work. ~ For exanll~ie, has’The top layer is acthem. A sample task in a floor-la!.out >ip- pc1-iinits ( p i stands for cessed by system analysts, plication might be specified a s simply problem doinain) reladesigiiers and users; the 1 “populate room.” Because iiscrs don’t tionships are instantiated hottom layer contains all the information for imhave to adapt their description to some when tasks are refincd. Istechnical or f o m d language that thc ana- represented relationships plementation, which has been derived from delystordcsigner uses, no infomiation is lost arc instantia red when signers at the top and inwhen tlie analyst or designer acquires the data inlist bc correlated terniediate layer and user’s task hiowledge. U ith interaction media. niadc accessible to pro- ~I T h e l i e d h v o levels contain temis that ’l‘he relationships in graniiners. ’Thus, relathe desiLgneruses to translate the user’s ’lbhle 1 arc those that task description into something program- generall!. arise rluring desigii, although 1 tionships have to he defined not only 1 niers can use to inipleincnt system hinc- the!- ciin he estended to include multiple within each L V S layer but also hetween tions. This intermediate specification, represe~it~ition of intcraction inedia, a s we layers. !I which concerns problem and interaction d e s c r i l ~later. .l’he desiqer begins hy Horizontal decomposition. Since several -domain data, is necessary because the de- identitjing the prohleni domain and the 1 sicper must derive all elementary system intcraction donlain on the Ilasis of user 1 knowledge categories can tie found within functions that will meet user require- tasks. This is kertical decoinposition. .I’he p t i c u l a r IhlN layers, horizontal decon- 1 ’ nients. Data about the Ixohleni domain heltis the dcsimier refine tasks to find data 11 structures for implementing the application. This step corresponds to the semantic dat:i modeling done with entit\.-relationship d i a p m s in databasc design. ’The result is a static description ofthe prot)lem domain Interaction domain in the fomi of :iconiplete list of G d g G y -Usertasks--oblem __________ _ _ _ _ ~_ task-relevant data, correlated by seinmtic _ ~ _ ~ 1 I \er t‘l‘A5 1 1 ‘ 1 5 suhtashs h ~ pd s units i s represented rela ti onships . I,eto1 e I h t a about the interaction-ineclia do__ has part IS represented is handled by main helps the clesigner relate all data 1 Problem domain is a items visible on the screen to interaction lntercictiondomain has part IS handled by I I media. T h e interaction domain not onl!. covers all visual occurrences of (IOCLIl l , nients, hut also captures the interaction 1 Svstem functions __ media required to inanipulate data in the Lr~
1
It represents Several
categories of specification knowledge, including use, tasks,problem doto, interaction medio and elementory system functions.
~
‘I
il ‘I
I
I1
i
~
~
lil
I‘
i
-
I Figure 2. Intwface fir nn application to design a flow in a house. The screen on the lefr is used by architects to position walls. The screen to the right is wed by interior designers to add fum1tui.e. As i t m s are added in one sn-een, they uppear in the othel-smen as well.
position lets you to group knowledge according to user task, problem-domain data, interaction-media data, and system functions. An example of horizontal decomposition is “a menu is-a window.” Window is an item in the interactionmedia domain, and is-a is a relationship to model that domain.
SAMPLE APPLICATION We applied IMNto create an interface system for laying out floors. In thls example, the task of designing a floor w i h a house is decomposed into subtasks solved by one or more persons using graphical workstations. An architect creates the structure of the floor by inserting walls, doors, and windows into the layout. An interior designer populates the ‘Ontext . Of . roomswithfllI7Llturesuch as desks, chairs, and closets. T h e interface provides the appropriate interaction media ‘Onsidered (windows, menus, mouse selections, pointers, and so on) to help both the archtect and designer. We also assume that other application tasks must be performed, such as generating a list of all furniture items,
calculating the price of the overall building, and constantly checking to ensure that user actions (like changing the wall structure or addmg furniture) do not make the house structure unstable. Figure 2 shows the interface for constructing a floor plan (the cmzvmct problem), which contains two work spaces. To the left, architects manipulate the physical structure of the floor plan; to the right, interior designers add or move furniture withln the walls.
-
Specification. Figure 3 shows part of the
LMNfor the construct problem. At the top layer is a hierarchy of user tasks and subtasks. T h e task Design Floor has three suhtasks: Create Floor Structure, Populate Room, and Calculate Price. These subtasks must occur chronolonically, which is denoGd through “before” relationships. Thi second layer represents horizontal decomposition into problem-domain data -floor, wall, window - and vertical decomposition into interaction-domain data -window, icon, menu, title bar, item. T h e hottom layer in the figure depicts
Interfaces are developed in the
user
yet problem data and . Interaction media are
28
all relevant elementary support functions by node. For instance, a database-management system must handle the problemdomain data for Design Floor subtasks. Clustering can occur throughout the IMN.In the figure, it occurs at the top layer to aggregate subtasks (shaded area). Insert Wall, Insert Door, Insert Window, Insert Table, Insert Chair, and Insert Cupboard can be clustered as elementary Insert subtasks. Another knowledge cluster concerning interaction media appears in the middle layer.
lmplmtatkn. T h e IMN provides all the information necessary to encapsulate attributes and operations for object-oriented design. However, to preserve the constraints declared by such relationships as “before,” we cannot implement the construct problem as a traditional objectoriented model. Instead, we have extended the model to let the interface handle unusual tasks that are llkely to arise in organizing such a complex system. An example is to let the interior designer fill rooms before the architect finishes setting up walls. Constraint specification lets a designer incorporate many functions in one system, yet provides the flexibilityneeded for easy maintenance and possible component reuse. Adding work spaces, moving functions from one work space to another, or
NOVEMBER
1992
combining functions is not dificult when all the eleinents of the L\mT can be represented in the implementation. ‘To do this, we provide satisfiaction code for each constraint and use a constraint solver to maintain constraint dependencies. In the object-oriented extension we proposc, tern= and relationships, the basic LKYTelements, are represented as Tenn and Constraint classes. We also use the Representation class to capture entire
IMNs. Term. Figire 4 shows the Tenn class hierarchy. ’Itrim within Ti” are depicted as shaded boxes, which contain the class name and depict class properties either as rectangles, which dcnote field attributes, o r diamonds, which denote methods. hIethods or attributes inay extend beyond the left inside box, which denotes a public attribute or method, which is one that can be accessed from outside the class. Ege describes this notation in more detail where. Specific IhlN ternis are captured ;is subclasses of Term. As the figure shows, Term has three attributes: name, coninent, and level. S a m e identifies 11 tenn, which is further amotated with coininem. Level reflects the L\LY layer in which the term occurs. Tenn also has three subclasses: + 7 k k . This subclass inherits attributes from Term and adds to attributes to account for any existing conditions before or after a task. + Unit. Unit scmes mainl!. as a base class for LMN nodes in the middle LCLY layer. It defines the attribute “cluster” to support the grouping of ~~r01)lenior interaction-domain units. Its derived classes are ProblernDomainUiiit and Interaction1)omaiIiUIiit. Problern-domain units may be split into subproblerm, which are identified through the amibute “prohlen1.” Interaction-doiil‘iin units allow you to specifi. target platforrns, like the X11 C.1‘indow~System or Clindows, and inode requirements, like direct manipulation or touch screen. + ,S~~fc7iil;iinitio,n.This su1)class captures inipleincntation-specific routines and may be specified with parameter lists
IEEE SOFTWARE
lipver II
29
I
’
and routine bodies. Functions concem both problem- and interaction-domain units. In the construct problem, “open floor database” (“open floor database” is part of the bottom-layer node DBMS, which is not shown in Figure 4) would be represented as an instance of SystemFunction that concerns a problem-domain unit. Its body attribute would contain the pseudocode to invoke appropriate database functions; the parameter amibutes would contain the necessary parameters. “Open window,” (also in the DBMS) on the other hand, would be represented as an instance of SystemFunction that concerns an interaction-domain unit. If system functions are combined into a single functional unit, such as the database management system in Figure 2 , the class hierarchy may need to be extended to accommodate more complex and combined system functions. Condmint. IMN relationships are represented by constraint classes. Figure 5 shows the class diagram for the Constraint class. Its two attributes encapsulate the constraint name and its description.Maintain is a public method that contains the procedural code to maintain the consn-aint. Constraint is the root of a class hierarchy that contains classes to represent all the IMN’s possible relationships. In the construct problem, relationships include has-subtasks, has-parts, is-represented, and is-handled-by, which are represented as Constraint subclasses HasSubtasks, HasParts, IsRepresented, and IsHandledBy. Each subclass defines three attributes: lhs (left side), rhs (right side), and constraint-satisfaction code. HasSubTasks relates objects of Task on its left side to a set ofTask objects on its right side. T h e nature of the constraint is captured with the constraint-satisfaction code, which is execvted from the inherited maintain method. Because the code must be different for each constraint class, it cannot be d e n t e d from the base class (Constraint).
Figure 4. Hierarchyfm the Term c1as.s.
Representotion.T h e Representation class, shown in Figure 6, captures entire IMNs.
Figure S.Hierarchyfm the Constraint class. -
30
I
NOVEMBER
1992
‘I
Gl~bdm~deling.Our extension to the 01)jecr-oriented model also lets yoii model and reason ahout the overall application. At the class level, designers deal with 11 categorical description of the interface. At the instance level, they can iiiodel circunstantial irifonnation. For example, suppose in the construct prol)lem you wish to consider the constraint that desks cannot tle placed on walls. ~ ) in io u ~ express c~ this constraint at the class level and niaintain it at the instance level. hlaintcnance occurs in the instance level hecause the constraint
~
Its attributes - teniis and constraints maintain the lists of’\b\L terns and relationships. Instances ofthis class p r o d e an entry point to all participating term and constraint objects that represent a coniplete IMK. T h e top layer ofthe LMN for the construct problem is represented as an instance ofRepresentation. Figure 7 shows a subset of the obiects involved. Obiects are deDicted with obiect diagrams, in which a hox shows an object labeled with the object’s name. T h e inside ofthe hox shows the object term ,and constraint attrihutes (first and second recmngles) with their values. If an attribute contains a reference to another object, a line coimects the amih e to that object. T h e object designRepresentadon is an instance ofRepresentation. Its ternis attribute (first remangle inside the box) contains a reference t o desigiiFloor’Iisk, createFloorTask, populateKooinTask and calculatePriceTask, which are instances of Task. ’IBe constraints attribute (second rectangle inside the box) refers to instances hasS Lib’l’dsksConstrai n t and before(:onstraint, which are instances of Constraint’s subclasses. Figure 6 does not show all the objects necessary to implement LMN for the construct problem; createFloo further represented by other objects to insert walls, doors, windows, and so on. T ~ s k sare completely represented only after coniponents of the window system arc added, which occurs at the next IhIN level. ’I‘he is-represented relationship is also captured as a n instance of the I IsRepresentedRy subclass of (:onstnint.
1
IEEE SOFTWARE
Yoit can also express constraints on class variables at the class level.
R
epresenting L\IS c o m p o n e n ~with our extended object-oriented paradigin proLides an a\.ailal)le iniplenientation path for interfaces clescrihed in a taskoriented specification. ‘l‘he use of constraints enal)les tlexible. user-oriented
:I---
system description. .As with any declarative apprwach, the efficiency of the implementation depends on the qualit) and speed of the algorithms used to satisfi. constraints, as M ell as the raw power ofthe ha rdwarc . .iccorcIing to ~ e i dSmnitli and colleagues,‘ a declarative task description has to capture ;it least +Ale computation required for each task and sutzxk, + the re~ationshipsamong tasks and required processing componcnts, and control tlou Ixtween tasks and
1 1
~~
i I
~i
1
Together the L\lS and constraint-l,ased object-oriented specification meet thesc ’~ requirenients, plus they make the interface easy to maintain and reuse. l *l’he resulting iniplenientatioii inaintains dcclarative specification throughout application development. ‘The high level , of declarativeness is reflected by the rcsultinp lo\+ nuniber of incthods for the ~
~
~
Real-Time Systems Desian and Analysis by Phillip A. Laplante This monograph provides acomprehensive guide to the practical design and analysis of real-time systems. It covers all aspects of real-time software design including computer architecture, operating systems, programming languages, software engineering, and systems integration. Many examples, illustrations, and exercises as well as practical tools which the software engineer can apply in the field or laboratory are presented. The text explores several new topics such as:
* * * **
The software Heisenberg uncertainty principle The application of petri nets anddata flow diagrams Queuing models to producer/ consumer analysis Multiprocessing issues Hardware/software integration issues
Sections Include: Computer Hardware Technologies; Software Design; Modeling Techniques; Inter-Task Communication and Synchronization; Memory Management; System Performance Analysis and Optimization; Queuing Models; Testing, Fault Tolerance, and Reliability; Multiprocessing Systems; HardwareBoftware Integration. c 350 pages October 1992 Hardcover ISBN 0-7803-0402-0 Catalog #3707 * $39 95 Members $32 00 ( * prepublication price)
Order toll-free
:lasses in the implementation,. such as ’opulate Room. T h e methods capture the mperative component of the interface. Many of the interface-component relaionships are captured declaratively as :onstraints. Another advantage is that :he separation of interface components is advocated by the Seeheim model, is >reservedeven to the lowest implementaion level. Our framework makes it possible to develop interfaces in the context of user
tasks, yet individually consider problem domain data and interaction media. By either activating or deactivating constraints, designers can connect the interface to application objects without losing the context of user tasks. They can also have multiple interfaces to common application objects, without the need to exchange knowledge about interfaces. T h e approach we propose is especially suited for rapid prototyping, in wluch execution speed is not the top concem.
+
ACKNOWLEDGMENTS This work has been sponsored in part by the Max &de Foundation; the CD-Lah for Expert Systems in Vcnna, Ausma; .and the Florida High Technology and Indusoy Council.
REFERENCES 1. D. Kieras and P. Polson, “hiApproach to the F o n d Analysis of Uqer Cfimpledty,” Irzt97. Mui?-,Zfachrrre S t d i e s , Sept. 198.5, pp. 365-394. 2 . M. Green, “Report on Dialog Specification Tools,”in WuilGrhup mz L h Inte?fbcr ,\.la?ragmmtSyzmzs, G. PfaE, ed., Springer-Verlag,Berlin, 1985, pp. 9-20. 3. R.Ege, D. ,Maier, and 4.Boming, “The FilterBrowser:Defining Interfaces Graphically,”in P n x Ezmpeiln Cmj:O@ert-OmntedProgrummriig, Lecture Notes in Computer Science 276, Springer-Verlag,Berlin, 1987,pp. 155-165. 4. 1).Epstcin and \I: L a h n d e , “A Smalltalk \4‘indow Systein Based on Constraints,” in Prac. ObJrcr-Orientrd Pmp-am, Syzems, Lrmnpges, u/ui,~lppliratiom,LEEE
