Previous | Table of Contents | Next |
Viewing Event Log Viewing the event log is started as soon as the operator wants to look at the text descriptions of the real-time event stream being received from the managed systems. The event log is the default destination of all received events and unless otherwise altered shows all events from all managed systems.
Figure 3.5 shows additional subcourses of transactions for the Viewing Event Log use-case. View event properties and the four extension uses cases capture the different likely actions the operator might take in reaction to a specific event they have chosen to view. The structure of the use cases defines a relationship between transactions with the system and captures an abstract view of the flow of these transactions.
The use cases themselves provide summaries across observations and specific individual differences, and can then support and structure design as a useful chunk of information. The scenario data (e.g., the quotations) are important just because they are not abstracted they capture the actual flavor of users understanding of their work and give evidence of users schemas for understanding their tasks.
3.2.2. Objects, Conceptual Models, Metaphors
Scenarios and use cases are the substance of the represented world. The information they contain must be transformed to develop correspondences with the representing world. Objects, conceptual models, and metaphors play a major role in this activity and are derived from the scenarios and use-cases to facilitate design of specific interface elements and flow. The objects defined here, although capable of having a formal connotation within a full Object-oriented system, can be thought of less formally as the entities upon which the user acts. The user actions can be thought of as services being requested of the object, but no formal requirement is made in this regard. A conceptual model is a simplified rendering of how proposed objects will behave and interact. The behavior in question is not just that of the graphical user interface per se, but of the software functions supporting that interface. One analogy here is between a blueprint and a finished house. The blueprint describes how the components of the house will be put together so that the finished structure is sound and can be used for the designed purpose. When you walk into the house you do not see many of the elements contained in the blueprint, especially if it was built correctly. However, it is possible to relate the finished appearance and the internal structure of the house to the blueprint. Therefore, a conceptual model is in a sense a user view of the architecture of the system, if such a view was to be revealed to the user.3 A conceptual model helps the user interface designer and the development team make consistent decisions across user visible objects of a system and to relate these objects to the internal system view. This definition is somewhat different from others in the literature because it emphasizes the integration of the user view with system behavior, instead of focusing only on the users conceptual model. A metaphor effectively likens a model or an aspect of the represented world to some other commonly understood object, behavior, or characteristic of the world. The metaphor then provides both literal and behavioral structure to the user interface. Conceptual models and metaphors should work synergistically as system design centers.
3Such models were used in documentation, information support, and training on this project, where they were the basis for explaining the application.
Conceptual modeling is useful for ensuring that internal system designs are projected selectively to the end user, or conversely, hidden as required. Figure 3.6 illustrates some aspects of an important conceptual model underlying the Monitoring scenario.
Figure 3.6 Conceptual model for distributed architecture and consolidated user view.
This figure shows six agents4 on the left, each of which can detect important changes within their domain (typically a single computer). These agents are software modules within monitored corporate servers. They send notifications of these changes to other servers running the system management application, which collect these events and store them, each in its individual log file. The large rectangle into which the servers place events is the event log viewed by the operator as part of the use case Viewing the event log. It is a consolidated repository of data (i.e., all the log files) based on a subscription constructed by the GUI client and sent to distributed event servers. Thus, the underlying software is responsible for supporting this virtual view. The end user sees this single log in the list view and only cares about the distributed sources if there is some problem making the virtual log incomplete. In the contextual inquiries, users made a clear distinction between the distributed elements they managed and their own requirement to have the application support a centralized, logical view of that distributed domain. Part of the user interface design problem was arriving at the correct user view of the information, its use, and the end users expectations. Part of the overall system design problem for support of the Monitoring use case was ensuring underlying software services were available to maintain and manage the virtual view.5 The conceptual model is important because it makes the potential impact of nominally internal design decisions explicit and thereby enables the designers to address how such decisions might affect end users.
4In this context Agent refers to an architecture component within a common management model in which an agent communicates with and can act on instructions from a Manager application to effect changes within the managed resource (object).
5This indirection also affects the definition of the underlying system architecture and thereby the structural elements or services made available to modules. A classic instance where system internals are painfully revealed to the end user in many network management systems occurs within the context of SNMP-based Management systems. Here typically the user must directly and in a piecemeal fashion manipulate low-level data structures because a data model has been equated with the user's view.
Table 3.1 summarizes some of the flow between the data gathered from users into scenarios and use cases, the generation of metaphors and models, and the subsequent selection of specific user interface components.
Previous | Table of Contents | Next |