Home > Articles > Software Development & Management > Object Technology

Designing with Idiom

  • Print
  • + Share This

3.5 Formulating Abstract Descriptions of the Interactive System

Descriptions generated from the early design material include the core model, a finer-grained task model, and the view model. It is useful to categorize these models together as abstract descriptions, even though the task and view models start to articulate some concrete user interface design choices and therefore the descriptions incorporate some non-essential interaction detail. The general categorization as abstract descriptions distinguishes these models from the concrete user interface design.

3.5.1 The Core Model

The core model of a system or application represents the part of the domain that is of interest to users of that system [van Harmelen 1994] and that is (to be) represented by the computer system. Like the domain model, the core model is a structural model that is concerned with referents and relationships between them, independent of user interface concerns. 7

The core model is based on a subset of the domain model. For the example here, the core model is a slight transformation of a subset of the domain model.

Different kinds of users will have different tasks to perform using the facilities offered by the system and may only be concerned with different, possibly overlapping, parts of the system. Identifying the boundaries of concern delimits and focuses subsequent user interface design. Idiom can use different core models with referents derived from user-specific sets of tasks for different kinds of users and would name these by preceding "core model" with an appropriate actor name. Thus, for example, assuming that normal users of the chat system use only the chat facilities and will not need to know about chat clients and chat servers, there is no mention of clients and servers in the normal user's core model. Chat system administrators would have server objects in the administrator's core model, thereby allowing the subsequent design of a user interface that enables the administration of servers. Such partitioning is discussed by Collins [1995, p. 190] as "partitioning the analysis model into system models for different types of users." Clearly, designers should assure themselves that different core models are compatible and conform to the corresponding domain models.

Here we call normal chat users local users. In developing the local users' core model, the starting point is the domain model, as shown in Figure 3.12. Because the design is for a single local user's interface, a local user is emphasized. In Figure 3.13, only the local user's address book is considered, and not those of other users. The model is then transformed, as shown in Figure 3.14, into a representation of a chat system for the local user. In Figure 3.14, other users are represented as address book entries called User.

Figure 3.12 Chosen domain model

Figure 3.13 Intermediate model

Early core model decisions strongly influence the resulting interactive system. Giving each local user access to only a personal address book is a design decision that illustrates how the interactive system can be limited from an early stage by particular design choices. In this case, the local user is limited to the use of entries in only one address book. The core model would have to be revised in order to model the use of other address books, such as shared corporate address books.

A singular System type is introduced in Figure 3.14 to encapsulate systemwide functionality and to act as an anchor for the other objects in the model. Any types participating in associations with the local user can instead be safely associated with the system type, because both types are singular and, at this level of consideration, there is implied reachability from the user to all core objects, including the system object. System is often referred to simply as "the system object" in the context of the core model. The system object serves as:

Figure 3.14 The local users's core model—this package is later represented as a type (in Figure 3.21)

  • A place for useful system operations, such as setting systemwide preferences, initiating major system functionality, or exiting the application.

  • A place for operations that create core objects, typically for those core objects that are directly linked to the system object.

  • An anchor for other objects in the model. In conjunction with relations between objects, the anchor ensures navigability to all objects in the model.

3.5.2 Finer-Grained Task Models

The coarse-grained task model in Figure 3.4 was limited to tasks that could be expressed without introducing tasks that reflect concrete interaction details. The task model is now extended to include more details of user interaction by moving the task model toward a finer level of granularity that expresses some concrete design choices. These choices are exemplified here by the implied use of dialog boxes in LeaveConversation, as shown in Figure 3.15.

Figure 3.15 A more detailed (or fine-grained) task model

3.5.3 The View Model

Whereas a core model is an abstraction representing a user's view of the deeper contents of the system, a view model provides a specification of how the user interacts with the system and provides the basis for subsequent concrete user interface design. A view model is composed of a static and a dynamic view model.

A static view model specifies the structure and contents of the user interface. The model is divided primarily into top-level views, each of which is implemented as a window or dialog box in a windowed environment. Top-level views are used to provide users with the information and the interactive facilities necessary for task performance. A view is composed of view objects that may be for internal view use or that may be rendered and provide interactive behavior at the user interface: some view objects exist to represent core objects or other view objects,8 and some view objects exist purely to specify interactive capability. In a static view model, top-level views and view objects provide an abstract specification of the composition of the interface and of some aspects of interaction. They do not reflect how the interface will be implemented.

A dynamic view model articulates the run-time view behavior of the system by describing the way in which top-level views are created and destroyed as a result of user interactions and system events. Identifying Top-Level Views

Because top-level views displayed as windows provide contexts for task execution, they should support the user in his or her task-based behavior by making available (a) representations of the application objects that the user needs to refer to and/or manipulate during task performance, (b) controls to invoke suitable operations, and (c) feedback during and after the operation invocation. Unless there are strong motivating reasons not to do so, the user interface design should cater to task execution without the user having to manipulate multiple top-level views in order to complete a task (see also Chapter 8). As such, all task-related information and functionality should appear in or be easily accessible from the view supporting the performance of that task. To further reduce view switching by users, views should, whenever possible, support the performance of related tasks.9 The analysis described here enables designers to (a) extract task contexts from task models for implementation as windows, dialog boxes, and tool palettes; and (b) inform the static and dynamic view modeling described in Sections and The techniques used here provide low-cost, low-commitment choices which allow for easy revision of existing choices.

The initial step is to choose tasks to be executed within particular task execution contexts that will be realized as windows. To choose task execution contexts, it is useful to annotate a task model: Figure 3.16 shows boxes drawn on a task model to represent contexts within which the boxed tasks can be executed. Overlapping boxes are necessary for tasks envisaged as being implemented with cross-window drag-and-drop operations. 10 The core objects and attributes that are used in task execution (revealed by referent identification from task descriptions in Section 3.4.4) can be recorded inside the corresponding boxes. This annotation enables the detection of any tasks using the same or similar information and, possibly, merging of the task execution contexts.

Figure 3.16 Tasks mapped to views (implemented as windows and dialog boxes)

It is also possible to use the annotated task model to record how task execution contexts are created by users prior to use. Arrows are used to show how new contexts are created. This information is later recorded more formally in the dynamic view model (see Section

The next step is to depict the boxes on the task analysis in a separate diagram. This is done in Figure 3.17. Moded dialog boxes are drawn with a heavy outline. One of these—the conversation invitation dialog box—is worth discussing here. Its modedness is a pragmatic choice that anticipates the prevention of unnecessary interaction when disconnecting at a later time, should an unmoded version of one of these views still be open. This is a design choice that needs to be evaluated with users; as an alternative, users might prefer unmoded invitations that can be left open so that a conversation can be joined later.

Figure 3.17 Potential windows and dialog boxes for task-execution contexts

The consideration of exceptional cases is important for user interface coverage in the developing design. Thoughts about the exceptional case of all invitees refusing the invitation to a conversation prompted the invention of an extra dialog box (see Figure 3.18).

Figure 3.18 Extra dialog box

This pointed to a failure in the scenario generation process and the need for subsequent reconciliation of the new dialogue with the scenarios, task models, and task descriptions.

Users of the method may wish to experiment with rendering views as shown in Figure 3.19.

Figure 3.19 Alternative view rendition View Behavior and the Dynamic View Model

Designers of systems need to be able to plan, communicate, and improve designs for the creation, deletion, lifetimes, and multiplicity of top-level views. A dynamic view model models this top-level view behavior.

Dynamic view modeling can be performed in a style that shows the particular paths of use and how each window, dialog box, or palette is created from another in a way similar to that shown in Figure 3.11. Constantine and Lockwood [1999] are two of the proponents of this kind of style. In their version, top-level views are represented by unadorned boxes. This kind of representation represents the description domain relatively directly, and it is easily understood by a wide variety of stakeholders. As such, it is noteworthy and significant.

However, there may be difficulties in using this form of representation to model all possible paths of view usage. Idiom solved this problem with, in retrospect, an overly complex form of parallel state machine called a view transition machine. Of primary interest to designers who like rigorous notations, a view transition machine (a) models the dynamic aspects of the existence of top level views and (b) specifies, at an abstract level, events leading to top-level view creation and destruction using threads akin to threads in a UML state machine. Details of this approach are omitted from this chapter, but the basic style of rendition, devoid of many annotations, appears in Figure 3.20.

Figure 3.20 A simplified view transition diagram View Structure and Static View Models

The static view model augments the core model with views and their contents based on previously formulated design information. Figure 3.21 shows the most abstract form of the chat example's view structure. The figure contains the core model, three views, and the user, who interacts with the core via the views. dialog boxes have not been shown, but they could be attached to the model via the views, thereby indicating the place from which they are "created."

Figure 3.21 Abstract view structure

The abstract form shown in Figure 3.21 is useful to record and convey an overall picture of the multiplicity of different types of top-level views. In the figure, we can easily see that there is a single system control view but an unlimited (at this stage, without machine constraints) number of Chat or Start Conversation views.

The composition of the top-level views is recorded by adding more detail to the model, as depicted in Figure 3.22. dialog boxes are again omitted; at this level of detail, they would be attached to the model via the source view and via any core or view types that act as information sources for the dialog box.

Figure 3.22 Core model, static view model, and user

The types which appear in static view models represent top-level views or view objects. They may be populated with operations that correspond to user actions. Thus the type Start Conversation View in Figure 3.21 could contain operations like:

  • selectParticipant()

  • chooseParticipant()

  • deselectParticipant()

  • inviteAllParticipants()

  • cancel()

In Figures 3.21 and 3.22 these operations could only appear in the Start Conversation View. However, placing an operation in a view object that constitutes part of a top-level view removes the necessity to list the operation in the top-level view type. Thus if the selection panel in Figure 3.11 had been modeled in Figure 3.22 with a Selection Panel type that was a constituent part of the Start Conversation View and that was associated with the User View type via associations labeled with the roles invited and not invited, then the first three of the above operations could be positioned in the Selection Panel with optional replication in Start Conversation View.

Sometimes, in making the transition between an abstract form like that of Figure 3.21 and a more detailed form as shown in Figure 3.22, the cardinalities become less than clearly expressive. This occurs for cardinalities on associations between core objects and view objects for those top-level views that may optionally exist once or more than once at a given moment at run time. In such a case it may be more useful to express the view structure as it is (partially) developed in Figure 3.23. There the larger boxes represent the core model type and a Start Conversation top-level view type, and the association between these boxes represents the optional "instantiation" of the top level view one or more times. The cardinalities between User and User View are now more reflective of the desired situation, that each of the users in the local user's address book (each of the set of instances of User in the core) is represented once in the Start Conversation View.

Figure 3.23 Partial refinement of a detailed static view structure

In terms of an abstract-to-concrete continuum, static view models provide intermediate-level descriptions; they articulate aspects of choices that specify concrete user interface design features. Imagine two different ways of initiating a conversation: (a) by using a dialog box (as illustrated in Figure 3.11) and (b) by dragging user photographs from an address book view to a chat view using drag-and-drop interaction techniques. These different forms of interaction would be articulated differently in the view model; in scheme (b), the Start Conversation view would be omitted from the view structure shown in Figure 3.21, and the user would interact by using a view displaying photographs of other users and a conversation view. Corresponding changes would be made at the more detailed level of Figure 3.22.

The construction of the view model can easily lead to re-evaluation of existing aspects of concrete design decisions. The positioning of invitee status feedback (accepted, refused, and so on) in the chat example was revised, in part, as a result of the informing role played by a static view model level consideration of the chat system. More Complex View Models

Idiom incorporates a general model of interactive system structure that can cater for transactions11 on the core model to enable query and interactive updates of the model [Wills 1988, van Harmelen 1994]. Transactions can be modeled with views and view objects.

The motivation for transactions in Idiom is derived from the observation that humans are limited in the things that they can do at one time and that under certain circumstances (for example, in editing an engineering drawing) modifications of core objects via the view model must be done one step at a time. This may perhaps leave the user's data in a temporarily inconsistent state. To avoid an inconsistent state, the changes are performed using a transaction that is a less stringently constrained copy of (part of) the core. When the transaction is again consistent in respect to the core's more stringent constraints, a change can be made to the core in a single transaction completion operation, and the transaction can be discarded. Thus, a transaction is a model-level representation of interactive capability.

There are three kinds of transactions, which are classified according to how they work:

  • A creation transaction first gathers all the information needed to perform a change in the core and then invokes an update operation on the core. This is a kind of change transaction; it changes the core. If the chat system gathered a transcript of a conversation and, when the conversation was finished, saved that copy to an archive maintained by the core, the system would implement a creation transaction.

  • A copy transaction is a less constrained "copy" of (part of) the core in which intermediate inconsistent core states are allowed and supported. To change the core after one or more changes have been made to the copy, a consistency check is run to see if the transaction is consistent with regard to core constraints, and, if so, an update operation is invoked on the core. This is a kind of change transaction.

  • A read transaction simply presents copy information drawn from the core model without the possibility of changing that information.

Transactions may contain a range of objects that have nothing to do with the domain of interest per se. Thus, a typical change transaction might contain objects representing whatever the transaction is being used to edit, as well as objects required for interaction, such as cursor position, selection markers, and cut-copy-paste buffers. (See [van Harmelen 1994].) If this detail is recorded in a static view model, the purpose is to articulate interactive behavior, not to specify implementation mechanisms.

A top-level view or a view object may also be a view in the Model-View-Controller (MVC) [Krasner and Pope 1988] sense, or, less confusing terminologically, an observer in the Observer pattern [Gamma et al. 1995] sense. Such an observer reflects the state of a subject that the observer watches; the observer is dynamically notified of changes in the subject and updates itself accordingly. The subject might be changed by one of its observers as a consequence of user interaction with that observer, or the subject may be changed as the result of a system event. The pattern is useful in the specification of interfaces which dynamically display changing system data (control systems, for example), and for the specification of interfaces where the same user-manipulated data is displayed potentially multiple times, possibly in different forms, and needs to be kept up to date each time it is displayed.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020