Information systems often support a variety of di erent device types like desktop computers, smartphones or tablets. Some can even be used in a cross-device manner, i.e., using multiple devices in parallel or being able to switch from one device to another while interacting with the system. Even though there is increasing support to implement such cross-device systems, existing modeling languages only provide limited means to specify them. In this paper, we present an extended form of UML use case diagrams, which allows to properly take the cross-device features of a system into account and serves as a rst step towards a model-based development process for cross-device systems.
Due to the availability of multiple devices, users start using information systems
in a cross-device manner [
During requirements analysis, use cases are de ned to sketch the functionality provided by the system under development. The relation between use cases, actors and other systems are visualized using UML use case diagrams. If it is not important which device type is used to interact with the system, e.g., when only a single device type should be supported, the standard use case diagrams su ce. However, when developing cross-device systems it is important to specify, which functionality is o ered by which type of device and what kind of interactions are possible. Standard UML use case diagrams do not support modeling such information. In this paper, we present an approach for the high-level modeling of cross-device systems in terms of extended use case diagrams. Our approach provides a clear separation of concerns and can be used during requirements analysis to pragmatically take cross-device interactions into account.
The remainder of this paper is structured as follows: In Section 2, we introduce two examples for cross-device systems and identify the shortcomings of standard UML use case diagrams. Subsequently, we present our extension to use case diagrams in Section 3. Related work is discussed in Section 4. The paper is concluded in Section 5, which also gives an outlook on future work. 2
This section provides two scenarios, which describe examples for cross-device systems. We explain the limitations of standard UML use case diagrams with regard to modeling cross-device interactions supported by such systems. Afterwards, we derive requirements for an approach to model cross-device systems with extended use case diagrams.
In the use case diagrams in this paper, we assume for associations between an actor and a use case a default multiplicity of 1 on the actor's end and 0::1 on the use case's end. Hence, by default an actor does not have to perform a use case but if a use case is performed, the associated actors are required.
Scenario 1: In this scenario a railway company wants to provide a ticket system, which enables users to buy tickets at Ticket Vending Machines (TVMs), on computers, and with smartphones. A smartphone is seen as special kind of computer, which is mobile and allows location-speci c services. It shall be possible that a customer starts the booking process on one device and migrates to another while keeping the current progress. This way the customer can start the booking process on his personal computer at home by selecting a train connection and choosing ticket options, pay with his smartphone on the way to the train station, and afterwards switch to a TVM to receive the ticket.
Figure 1 shows three di erent ways to model this scenario with UML use case diagrams: (a) Each device type is represented as a system and the use cases are duplicated if o ered by multiple device types. (b) The device type information is weaved into di erent actor roles. Using this approach, we are also able to express that a smartphone is a special kind of computer. (c) For each device type a separate use case is created. In all three diagrams, we face the problem that the device usage information (computer, smartphone, and TVM) is mixed with other concerns. Additionally, it is not speci ed that it is possible to migrate from one device to another. In (a) and (c), migration possibilities could be speci ed using «extend» associations between the use cases. However, modeling transitions between di erent devices with «extend» associations is not be very intuitive because the use cases are not extended just the device is changed. Moreover, using «extend» relations is not possible for variant (b), since we only have a single use case for all device types. Customer
Ticket Vending
Machine Book a
Ticket Computer
Book a
Ticket Smartphone
Book a Ticket (b)
Ticket System
(c)
Customer at a TVM with a Computer
Book a Ticket
with a Smartphone
Customer
Ticket System
Book a Ticket at a TVM Book a Ticket with a
Computer Book a Ticket
with a Smartphone
Scenario 2: In the second scenario, a system shall be developed which allows students to collaboratively work on a document, while they are supervised by a teacher. The system shall allow each student to contribute by using their own tablet and/or to collaborate with other students using smart board located in each classroom. So there is a one to one relation between a tablet and a student as well as a many to one relation between students and a smart board.
We omit a standard use case diagram for Scenario 2, since none of the approaches used for Scenario 1 really helps to de ne the Scenario 2. Modeling the device types as separate systems or duplicating use cases for each device type is not feasible for Scenario 2, because students could be involved with the same instance of a document editing use case on di erent devices. The approach of specifying the device usage along with the actors does not work either, since it does not allow to specify how many student can use a device. In Section 3, we present an extended use case diagram depicting Scenario 2.
Summarizing, we derive the following requirements for an approach to specify cross-device interactions in extended use case diagrams:
R1 Explicit device type modeling: Device types being relevant for the system must be modeled explicitly so that it is clear which device types are in the scope of the system.
R2 De nition of device usage: A use case might involve multiple human actors which use certain devices to interact with the system. It must be speci able which device types have to be used and by whom.
R3 Variability in the device usage: Human actors may have the choice between di erent device types to perform a use case. Such variability in the device usage must be expressible.
R4 Speci cation of cross-device interactions: Cross-device interactions like distributing a use case across di erent devices or migrating from one device to another must be speci able.
Use Case Diagrams for Cross-Device Systems In this section, we present our extended use case diagrams for modeling crossdevice systems. We use the scenarios from previous section to explain our approach and show how we address the Requirements R1 to R4. In the following, we use lled out circles like ¶ to refer to certain parts of Figure 2.b, which shows the extended use case diagram for Scenario 1 and hollow circles like À to refer to certain parts of Figure 3, which shows the diagram for Scenario 2.
To explicitly de ne the device types being relevant for the system (see Requirement R1), we de ne a device type taxonomy. Figure 2.a shows an example of such a taxonomy for Scenario 1. At the top of any device type taxonomy is the class \Device", representing any kind of device. Below more speci c device types are declared, in our example TVMs, computers, and smartphones as special kinds of computers. In contrast to Figure 1, the relevant device types are now explicitly listed and their hierarchy is not hidden in the inheritance between actors like in Figure 1.b. (a)
Device
(b) Computer
TVM
2 Smartphone
Customer
1 «device type»
Computer «device type»
TVM
3 4 0..* «migratable»5 Book a Ticket
In order to address Requirement R2, we use classes marked with the stereotype «device type» (see ¶) to reference a device type de ned in the taxonomy. Consequently, the name of a device type class must match a device type of the corresponding device type taxonomy. In extended use case diagrams, we use device type classes to re ne the association between human actors and use cases. This is done by indirectly associating a human actor with a use case, i.e., a human actor is associated with a device type to describe that a human actor uses a certain device type (see ·). Additionally, a device type is associated with a use case to describe that the interaction of a human actor with this use case is done via this device type (see ¸). Thereby, we can de ne the device usage explicitly instead interweaving it with other concerns. In Figure 2.b, the human actor Customer is associated with use case Book a Ticket over the device types Computer and TVM, meaning either of these device types can be used to book a ticket. This also implies that a smartphone can be used for this use case because we have de ned in the device type taxonomy that a smartphone is a special type of computer (see Figure 2.a).
In Section 2, we de ne that the default multiplicity is 1 on the actor's end and 0::1 on the use case's end. For our language extension, we de ne it in a similar manner: The default multiplicity on an association between a human actor and a device type is 1 on the human actor's end and 0::1 on other end. Thus, not every human actor has to use all devices but when a device is used, the associated actors need to be present. Similarly, the default multiplicity on associations between a use case and a device type is 1 on the device type's end and 0::1 on the end of the use case. Thereby, the default multiplicities de ne that not every device necessarily has to perform all use cases to which it is connected but if a use case is performed, the devices are required.
We are able to de ne the relation between actors and devices as well as between devices and use cases more precisely by using multiplicities. For instance, we can specify that a TVM can only be part of one ticket booking session at a time, while a computer can be part of multiple sessions, which is de ned by the 0:: multiplicity (see ¸). On this abstraction level, a session includes a use case instance along with the involved actors and devices. Furthermore, we can express for Scenario 2 that multiple students can use a smart board (see À) but there should only be one student per tablet.
1 1..*
«device type» Smart Board «device type» Tablet 2 0..* 3
Edit Document
«extend» Supervise Students «device type» Tablet
Requirement R3 states the need to express that a variety of di erent device
types might be used to perform a use case. We o er two possibilities to specify
this variability: (i) Either we choose a common ancestor of device types which
shall support the use case or (ii) by explicitly listing the device types supporting
the use case. In Figure 2.b both options are used. By specifying that a
computer can be used, it is implied that also a smartphone can be used, since a
smartphone is a special type of computer (c.f. Figure 2.a). Whereas the TVM is
explicitly listed since it is not de ned as a special type of computer. To express
the variability in the device usage, we enrich the concrete syntax of UML use
case diagrams with OR and XOR operators known from feature diagrams [
Requirement R4 demands that cross-device interactions must be speci able. For this purpose, we introduce the stereotype «migratable», which can be applied on use cases (see º) to de ne that the device being used can be substitute at runtime by another device while keeping the state, as for example described in Scenario 1. The possibility to distribute a use case on multiple devices can be speci ed by using multiplicities with upper bound greater than 1 or by allowing the usage of multiple device types for a use case. In Scenario 2, a document can be edited on multiple tablets in parallel as de ned by the multiplicity 0:: (see Â). Moreover, the OR operator allows that both device types can be used at the same time (see Á). Hence, a smart board can be used in addition or as an alternative to multiple tablets.
The di erent stereotypes introduced by our approach are speci ed as a UML pro le. The usage of OR/XOR operators is optional, since they could be de ned, in a less readable form, using UML constraints. Even though it is not commonly used, the UML meta model does not forbid to associate actors and use cases with classes (in our cases classes representing device types). Hence, aside from our UML pro le, no additional changes to the UML meta model are necessary.
Our approach provides a clear separation of concerns by modeling device usage as an additional dimension in use case diagrams instead of interweaving it with other concerns like systems, actors or use cases (cf. Figure 1). This allows changing the level of abstraction or the viewpoint whenever needed in the respective project. For instance, cross-device interactions may not be of interest in any case or for all stakeholders. In such a case, we can automatically abstract from device usage by replacing an association from an actor to a device type and from a device type to a use case with an association between the actor and the use case. Similarly, it would also be possible to change the viewpoint by focusing on use cases o ered by certain device types, or alternatively, by focusing on the device usage of certain use cases.
In addition to use case diagrams, there usually exist further speci cations for
each use case. For instance, a textual description as well as an integrated process
diagram of the di erent scenarios of a use case, which visualizes what has to be
done in order to reach the goal of the use case. The device usage de ned in
extended use case diagrams can be re ned within such process diagrams using
our approach presented in [
The development of cross-device systems is supported on various levels. On the
implementation level, approaches like Panelrama [
We model variability in the device usage in use case diagrams. The lack of
means to model variability in use case diagrams is also identi ed in [
The Systems Modeling Process (SYSMOD) [
Adapt Cases [
In this paper, we have presented extended use case diagrams which can be used during requirements analysis for the high-level modeling of cross-device systems. In contrast to standard UML use case diagrams, our extension enables the modeling of device usage as a separate concern and allows the speci cation of cross-device interactions by re ning the association between actor and use cases. Thereby, we can pragmatically specify for use cases which device types can be used and by whom they are used. Due to the clear separation of concerns, it is possible to change the viewpoint if needed, e.g., by focusing on a certain device type or use case. We have illustrated the bene ts of extended use case diagrams with two examples of cross-device systems. We have de ned our extension as a UML pro le with an optional addition to the concrete syntax of the UML.
We are working on supporting further steps of the model-based development process for cross-device systems, i.e., a method to re ne the device type taxonomy to a device type model which allows managing concrete devices at runtime. In addition, further types of models will be considered in the future in order to cover other aspects like specifying the architecture of cross-device systems.