view release on metacpan or  search on metacpan

t/sample.xml  view on Meta::CPAN

   <listitem>
    <para>Human-Computer Interaction (HCI) is concerned with user interface &amp; interaction.</para>
   </listitem>
   <listitem>
    <para>CSCW has identified different degrees of coupling and different mechanisms for sharing.</para>
   </listitem>
   <listitem>
    <para>Ubiquitous computing (UbiComp) has to deal with device heterogeneity and their relation to the environment in which they are used.</para>
   </listitem>
   <listitem>
    <para>And, finally, separating specific concerns and defining levels of abstraction are very important software modeling techniques.</para>
   </listitem>
  </itemizedlist>
<para>
<inlinegraphic fileref="" width=""/>
</para>
<para>Figure 4‑2.1. Contributions to roomware applications by the different research areas. Figure 1-1.1 is extended to show the contributions of every involved research area.</para>
<para>These contributions can be arranged as three design dimensions: separation of concerns, coupling and sharing, and level of abstraction. While the contributions “degree of coupling” and “level of abstraction” define a dimension on their ...
<para>These three design dimensions – separation of concerns, coupling and sharing, and level of abstraction – constitute the basic dimensions of the conceptual model proposed in this paper. Each of these dimensions will be discussed in the follo...
<para>The model presented here is an updated version of the model published in [[BEACH-SyncCollaboration]], adding the third dimension for coupling and sharing. In addition, a graphical notation to visualize the model in design diagrams is proposed.<...
<para>As described above, it is necessary for different devices to have different user interface elements (req. ). Also, different tools are useful depending on the device(s) at hand (req. ). In order to achieve the flexibility needed for different d...
<para>
<inlinegraphic fileref="" width=""/>
</para>
<para>Figure 4‑2.2. Dependencies between data, application, user-interface, environment, and interaction model</para>
<para>The data model specifies the kind of data the users can create and interact with. To work with data, a application provides the necessary functionality. These two models are independent of the currently used or supported hardware device. Instea...
<para>In the following, these five models are presented in more detail, including their relationship to the previously identified requirements. Concrete examples of how these models have been applied are given afterwards.</para>
<para>Data Model: Information Objects</para>
<para>It is a very common approach in application modeling to separate the application model from the data or domain model [[VisualWorks-UsersGuide], [HUMANOID-Model]]. The data model relates to the information dimension identified by [ :inline | [Ja...
<para>Different applications can be specified and implemented for one kind of data. This can save much time if the current application domain has complex data structures or algorithms. On the other hand, application models can be reused for different...
<para>The data model defines the classes and functionality of all objects that can be part of a document. According to an object-oriented view, data objects combine document state with methods to change the state. In the context of cooperative work (...
<para>Following an object-oriented approach, the data model will usually consist of a network of multiple connected objects. For hypertext-like documents, e.g., it is popular to define one main containment hierarchy with additional connections define...
<para>Depending on the actual application, data objects are not restricted to represent what is classically seen as a “document”. In [[PlacelessDoc-Generality+Specificity]] a much broader view on documents is described. If, for instance, physical...
<para>Looking at the example of the Passage system, the data model covers all objects that should be attached to and carried with a passenger object. The implementation described below (see section ) supports the generic document elements provided by...
<para>Application Model: Application Behavior</para>
<para>Application models are used to describe all application aspects such as manipulation of data objects. As application models define the behavior of the application, they specify control objects as defined in [[Jacobson-OOSE]].</para>
<para>For a “text” object, the data model includes the string describing the text and text attributes like font or size. The application model adds the editing state for text, for instance, cursor position or selection.</para>
<para>Further, it can specify the degree of coupling between different users, i.e. it controls which parts of the editing state are shared by which users, and where private values are allowed. The workspace application model, e.g., allows specifying ...
<para>To be able to use different application models for the same data model, the data model has to be unaware of any application model and represent document state only.</para>
<para>It has proven helpful to choose a rather fine granularity for some application models. This way, low-level application models with a well-defined functionality (e.g. to edit a simple text) can be aggregated to form more complex models at a high...
<para>Using small application models turns out to foster a new conception of what is regarded as an application. The application model is seen as a description of additional semantics for a data model, instead of the conventional approach of seeing d...
<para>The Passage system, e.g., defines no new application model. Instead, it reuses the application models that are available for the data objects being attached to passengers. In fact, it associates the application model with a passenger object (in...
<para>User-Interface Model: Interface Elements</para>
<para>As traditional operating and window management systems have been designed for use with a traditional desktop PC, the interface they offer has drawbacks when used with devices not having a mouse and keyboard or having different forms and sizes. ...
<para>Therefore, the user interface aspects have to be separated from information and behavior of applications. This is related to the interface dimension identified by [ :inline | [Jacobson-OOSE]]. However, the BEACH conceptual model further disting...
<para>In the case of the Passage system, the user interface is rather simple; it consists of the virtual part of the bridge. The virtual part of the bridge is displayed on a roomware component whenever a passenger is detected on the physical part of ...
<para>The user-interface model allows one to define alternative user-interface concepts suitable for different interaction devices (req. ). Multiple-computer devices (req. ) and multi-device interaction (req. ) make it necessary to have user interfac...
<para>By explicitly modeling an appropriate user-interface, all issues related to the hardware and physical environment can be addressed at one point, allowing applications and documents to be device-independent.</para>
<para>Environment Model: Context Awareness</para>
<para>One major property of ubiquitous computing environments is the heterogeneity of the available devices. In order to provide a coherent user experience [[DisappearingUI-CoherenceScope]], the “system must have a deeper understanding of the physi...
<para>Therefore, the environment model is the representation of relevant parts of the “real” world. On one hand, this includes a description of which devices are used, how they are configured, and which capabilities they have. This is the direct ...
<para>In addition, other aspects can be included if they can influence the behavior of the software. Necessarily, it has to be possible to measure their relevant properties with sensors. Depending on detected changes in the physical environment, furt...
<para>The Passage system is an example of how to react upon changes in the physical environment. As mentioned, the virtual part of the bridge is shown as soon as a physical object is detected on the physical part of the bridge. Thus, Passage needs to...
<para>Besides the physical environment, other contextual information – such as the current task, project, or presence of co-workers – could influence the behavior of the software, so long as this information is available to the application. This ...
<para>Software with functionality depending on physical objects and their properties, or other aspects of the user’s environment (req. ) is called context-aware [[ContextToolkit-AppDevelopment]]. There is a strong need for context-aware application...
      <para>However, using detected context to trigger functionality always has the danger of relying on misinterpreted information, which can be very annoying for users.</para>
</footnote> Therefore, the environment model must be capable of expressing relevant information, such as spatial relationships between physical objects.</para>
<para>Interaction Model: Presentation and Interaction</para>
<para>To be able to support different styles of interaction (req. , ), the interaction model specifies how different interaction styles can be defined. The term used here describes a part of the software architecture, and should not be confused with ...
<para>As shown in figure 4-2.2, the interaction model defines a way to interact with all other basic models. This is necessary, as all models can define aspects and functions that can be represented for and accessed by the user. For example, a data o...
<para>As an appropriate interaction style depends on the available interaction devices and the associated user interface, a suitable interaction model can be chosen depending on the environment and user-interface model. For visual-based interaction, ...
<para>Passage defines an interactive visual representation (for the virtual part of the bridge) and physical actions as input (placing objects on the physical part of the bridge). Consequently, its interaction model uses both a visual interaction mod...
<para>Whenever multiple devices are involved in a software system, the question arises, which parts of the system should be local to a device or shared between several. This has to be clarified for both the application code and its state. While distr...
<para>Today, many applications still run entirely local to a single computer, or access only data that is distributed over a network. Aiming at synchronous collaboration, crucial aspects of traditional CSCW systems are access to shared data and coupl...
<para>In the context of ubiquitous computing environments, this view has to be extended. In addition to data and application, also information about the physical environment, e.g., the presence of nearby users or other available interaction devices, ...
<para>As discussed above, in a ubiquitous computing environment elements of the user interface can be distributed among several machines (req. ) or among different devices (req. ). Based on the separation of concerns that has been previously identifi...
<para>Depending on how much state is shared, the degree of coupling can be controlled. If all involved user interface and editing state is shared, a tightly coupled collaboration mode is realized; if only the same data model is shared, users work loo...
<para>Even, if some models are not coupled, one can profit from sharing environment, user interface, and application models. As the information encapsulated in the models is accessible to all clients, it is possible to provide awareness information i...
<para>Beyond the provision of awareness in CSCW systems, sharing the environment model allows a new kind of awareness for ubiquitous computing environments. The information embodied in the environment model can be used to give environmental awareness...
<para>This section discusses the aspects of sharing the basic models. Before starting a detailed discussion, it has to be noted that “sharing” can be implemented in many different ways. In the case of collaborating devices with quite varying prop...
<para>Sharing the Data Model: Collaborative Data Access</para>
<para>In order to access and work collaboratively with shared data (req. ), it is widely agreed that a shared model for documents reduces the complexity in dealing with distributed applications. While there are well-established models defining a shar...
<para>Most popular toolkits and frameworks for computer-supported cooperative work provide some mechanism to manage a shared-object space. In toolkits with a centralized architecture [[Rendezvous-Demands]], the document is necessarily shared. Replica...
<para>Application designers thus have to decide to which degree or for which parts of their application shared access to data is desirable or necessary. For the Passage system, a shared data model enables a straightforward access to data objects from...
<para>Sharing the Application Model: Workspace Awareness &amp; Degree of Coupling</para>
<para>To have an easy way of getting information about the editing state of other users, it has been proposed not only to share the data model, but also to share the application model [[COAST-Model]]. Sharing the editing state gives the ability to pr...
<para>By changing the state of the application model, the degree of coupling or other possible work modes can be controlled (req. ). Users working with the same application model can work tightly coupled with rich awareness information [[COAST-Model]...
<para>Again, the application designer has to decide whether or not a tightly coupled work mode should be supported or how much awareness information is advantageous. As already mentioned, the Passage system allows transporting both data and current e...
<para>Sharing the User Interface Model: Distributed &amp; Coupled User Interfaces</para>
<para>If one user interacts with different devices at the same time (req. ), it is desirable that their user interfaces are coordinated. This is only possible, if the information about the currently used user interface elements is accessible to all i...
<para>In addition, some devices actually have several embedded computers (req. ). When a visual interaction area crosses the borders between displays that are physically placed next to each other, but connected to different machines, it is necessary ...
<para>However, for the Passage system, a shared user interface model is not necessary. It is sufficient that the virtual part of the bridge runs as an application local to each computer equipped with a bridge. Nevertheless, if the user interface is s...
<para>Sharing the Environment Model: Environmental Awareness</para>
<para>When several people and devices physically share a common environment, it is obvious that applications that are used in such situations can benefit from a shared model of how their environment looks.</para>
<para>In ubiquitous computing environments, many different devices have attached sensors that allow detection of some aspects of the physical environment. By combining all available information and making it accessible to other applications, it is po...
<para>For a system such as Passage, a shared environment model – similar to a shared user interface model – offers possibilities for extensions. In fact, for the example extensions used to illustrate the benefits of a shared user interface model,...
<para>Sharing the Interaction Model: Disaggregated Computing</para>
<para>Advantages of implementing data, application, user interface, and environment model as shared objects to give several users or devices the possibility to access these objects simultaneously have been discussed. In contrast, some interaction mod...
<para>In a ubiquitous computing environment however, the computer, to which an interaction device is attached, should become irrelevant, leading to what is called “disaggregated computing” [[EasyLiving-UbiComp]]. Systems such as PointRight [[iRoo...
<para>Another benefit of a local interaction model is the ability to adapt the interaction style according to each client’s local context, especially its physical environment and interaction capabilities. An extensive example of how local interacti...
<para>For the Passage system, though, a local interaction model is sufficient. The visual representation of the virtual part of the bridge has to be rendered locally at the computer, to which the roomware component’s display is attached. This is no...
<para>The third dimension of the conceptual model is the level of abstraction. It is a widely used software engineering technique to separate different levels of abstraction in order to reduce the complexity on each level [[Dijkstra-THE-structure], [...
<para>While the C2-architecture places different functionality at different levels [[Chiron-2-Architecture]], we rather see the level of abstraction being orthogonal to functionality. As different functionality should be separated by different basic ...
<para>In practice, the number of levels actually used may vary. In the context of framework development, it has been recommended to define three layers as part of the functional view on the architecture [[BuildAppFWs-FWs+DomainModels]], the environme...
<para>Still, besides the three commonly acknowledged levels, one additional level, the model level, is needed to represent common abstractions for all basic concerns (fig. 4-2.3) in an application-, domain-, and platform-independent way. Please note ...
<para>
<inlinegraphic fileref="" width=""/>
</para>
<para>Figure 4‑2.3. Four conceptual levels of abstraction: core, model, generic, and task level</para>
<para>The remainder of this section discusses these levels, starting at the bottom with the core layer.</para>
<para>Core Level: Specialized Infrastructure</para>
<para>The core level provides functionality that will make the development of the higher levels more convenient and portable by encapsulating platform-dependent details. Functionality normally provided by the (meta-) operating system, middleware infr...
<para>For roomware applications, additional functionality may be necessary, which is not available from off-the-shelf libraries or toolkits. This can include support for multi-user event handling, or low-level device and sensor management. For instan...
<para>Model Level: Abstractions to Ensure Platform-Independent Separation of Concerns</para>
<para>The aim of the model level is to provide application-, domain-, and platform-independent abstractions to be used as the basis for the definition of higher-level abstractions. These abstractions can be implemented on top of the core level. This ...
<para>Components at the model level typically define abstract classes that allow different implementations for different platforms, e.g., using the Abstract Factory or Bridge pattern as defined in [[GoF-DesignPatterns]]. For the platform-independent ...
<para>The Passage system uses the abstract definition of sensors and application models provided by the BEACH framework. This way, arbitrary sensors can be used to detect objects and arbitrary application models can be attached to passengers. To impl...
<para>Generic Level: Reusable Functionality</para>
<para>One important goal of every software system is to provide generic components that are useful in many different situations and for different tasks (req. ). Each application domain has common concepts and algorithms that can be applied by a numbe...
<para>Generic and domain-specific models and concepts should therefore be grouped at a generic level. This way, the designer is forced to think about generic concepts, which will lead to the implementation of reusable elements.</para>
<para>For example, the Passage system uses the generic document elements defined by the BEACH framework to be associated with passenger objects, instead of defining document elements on its own.</para>
<para>Task Level: Tailored Support for Specific Tasks</para>
<para>When generic elements only are defined, this obviously restricts the usability of the application to some limit. For some tasks, it is of help if specific support is given (req. ). Therefore, the conceptual model needs a task level, which group...
<para>The overall Passage system is located at the task level, as it supports the task “transportation of information (including its current editing state) between roomware components”. It relies on generic models, only defining the high-level us...
<para>With the three dimensions that have been discussed in detail, the overall conceptual model can be visualized as shown in figure 4-2.4. Looking at the dimension of the level of abstraction and the dimension of the separation of concerns, these t...
<para>
<inlinegraphic fileref="" width=""/>
</para>
<para>Figure 4‑2.4. Notation for the three design dimensions of the BEACH conceptual model</para>
<para>The BEACH conceptual model can be used as the basis to structure architectures and applications for ubiquitous computing and roomware environments. Figure 4-2.4 suggests a graphical notation that can be used in design diagrams to denote the pos...
<para>In favor of being applicable to a wide range of applications and architectures, the model specifies a coarse-grained structure at a high level of abstraction. Thereby, the conceptual model leaves much freedom for application developers and arch...