Open Journal of Applied Sciences, 2012, 2, 180-183
doi:10.4236/ojapps.2012.23026 Published Online September 2012 (http :/ /www.SciRP.org/journal/ojapps)
A Mapping Method of Using the Compound Use Cases
to Generate User Interface
Bingbing Xia, Yue Zhang
Information Technology Department, Shandong Jiao Tong University, Ji Nan, China
Email: jennifer_xiababy@yahoo.com.cn, lv1919@163.com
Received July 7, 2012; revised August 5, 2012; accepted August 16, 2012
ABSTRACT
To support the requirement analysis of the user interfaces and the auto generation of the final user interfaces, we should
improve the traditional modeling method which centered on the system and the implementation, and turn to use the
modeling method which centered on the usage and the user. The compound use cases describe the system function from
the user point of view. Based on the compound use cases, we can gener ate the final user interfaces.
Keywords: Compound Use Cases; User Interfaces; Modeling Method
1. Introduction
To support the auto generation of the user interfaces, this
paper introduces the compound use cases. The compound
use cases combine the UML concept of the use case
model and the concept of the data flow diagram [1]. The
compound use cases have its own character system; it
can break down into th e following parts.
1.1. Compound Use Cases Group
The compound use cases can divide into different groups,
and the use case group contains one or more groups,
every group has its own group name, thus the level rela-
tionships between the use cases will be more clear [2]
which will help the layout of the user interface and the
auto generation.
The use cases group is easy to map the menu, and the
group will make the use case diagram more clear and
easy to communicate with the user.
As shown in the Figure 1, the use case 1 and the use
case 2 belong to the same use cases group: group 1 and
the two use cases belong to the same menu group in the
final user interface menu. The use case 3 is not belonging
to group1 and th e grou p1 will not appear in the menu.
1.2. Roles and User Group
Roles represent different and direct users. The user inter-
faces should meet the requirements of all the system us-
ers. Different users play different roles in the system. So
the concept of roles is to differentiate different users. The
roles indicate the importance of the existence of the user
interface.
Different roles can divide into different user groups.
The concept of user group manages the system users at
different levels [3], assigns user operating privileges and
divides system function at different size.
1.3. Relationships
According to the feature of the user interface design ori-
ented, the compound use cases extend and modify the
relationship between use cases of the traditional use case
model, which can better support the requ irement analysis
and design and auto generation.
As shown in the Figure 2, the relationship named
function use represents function use relationship, the re-
lationship named extend represents extend relationship,
the relationship named refine represents refine relation-
ship, the relationship named navigate represents navigate
relationship.
usecase1
usecase2
usecase3
Actor
group1
Figure 1. Use case group.
Copyright © 2012 SciRes. OJAppS
B. B. XIA, Y. ZHANG 181
1.4. User Interface Contour Line
The compound use cases use the concept of user interface
contour line, which includes the composition of the user
interface in the use case diagram. The concept of the user
interface happens during the requirement analysis [4].
From the user point of view, he can see the composition
of the user interface during design, so he can participate
in the design. From the designer point of view, this con-
cept gives props for t he rep resent at i on of t he navi gat i on.
As shown in Figure 3, the use case navigates the user
interface UI1the rectangle represents the user interface.
As shown in Figure 4, the user interface UI1 is com-
posed of use case 4 and use case group group1 which
composed of use case 2 and use case 3.
2. Solution
The analysis and design of the user interface using the
<<functionuse>>
Actor
<<refine>>
UserInterface
UseCace
<<extend>>
Figure 2. Relationship.
usecase
Actor UI1
<<extends>>
Figure 3. Navigate relationship.
Figure 4. User interface composition.
compound use cases should follow several steps:
First, refine every compound use case, determine its
function, turn the user’s requirement to compound use
case diagram.
Second, determine the relationships between the com-
pound use cases and the relationships between role and
the compound use case, further refine compound use
cases, thus the compound use case diagram composes of
role and co mpound use case and all k inds of relationship
[5].
Third, determine the compound use case groups and
user interface contour line; determine the scope of every
interface. Every compound use case has its own parame-
ters, such as the compound use case belongs to group or
not, the compound use case belong to interface contour
line.
The compound use case diagram can directly map into
the user interface, so the concept in part I will directly
map into the compositio n of the interface.
2.1. Menu
As shown in Figure 5, this menu is generated from Fig-
ure 1. In this menu, use case 1 and use case 2 belong to
the same menu group, because the two use cases belong
to the same use case group. But the use case group does
not appear in the menu.
2.2. Relationships
The relationships between use cases can be described as
shown in Figure 6. Different relationship uses different
arrow character system.
Function use relationship:
This relationship is composed of the role using the
compound use cases and compound use cases using com-
pound use cases. The role using the compound use case
indicates that the role has interactive relationship to the
compound use case.
Figure 5. Menu gener ated from compound use c a se.
Copyright © 2012 SciRes. OJAppS
B. B. XIA, Y. ZHANG
182
The function use relationship is as shown in Figure 7.
The actor has function use relationship with use case 1
and the use case 2 has function use relationship with use
case 3.
Refine relat i on shi p:
The refine relationship represents the level relationship
between the compound use cases. The use cases can di-
vide into several sub use cases which can be divided fur-
thermore. The use case divided is not existed indeed, it
represents abstract concept [6]. The refine relationship
can map into several level menus, the use case divided is
not in the menu, and the sub use case is the menu item.
The use cases coming from the same use case belong to
the same menu group.
As shown in Figure 8, the use case 1 can be refined to
three use cases and use case 1.2 can be refined to three
use cases. In the generated menu, the use case 2.1, 2.2
and 2.3 belong to the same men u group because these use
cases is refined from the same use case.
Extend relationship:
One compound use case can extend to several sub use
cases which can extend furthermore. The compound use
functionuse navigate
extend
refine
Figure 6. Relationship character system.
usecase1
Actor
usecase2 usecase3
Figure 7. Function use relationship.
usecase1
usecase1.1
usecase1.2
usecase1.3
usecase2.1
usecase2.2
usecase2.3
消息1
消息1
消息1
消息1
消息1
消息1
Figure 8. Refine relationship.
case extended is existed. The extend relationship can
map into several level menu, the use case extended is in
the menu as menu item, the sub use case come from this
use case will act as the sub menu.
As shown in Figure 9, the use case 1.2 is extended to
three use cases. In the generated menu, the use case 1.2 is
existed in the menu, the use case 2.1, 2.2 and 2.3 act as
the sub menu of the menu named use case 1.2.
Navigate relationship:
The navigate relationship represents the trigger and
jump relationship between the user interfaces. Only the
compound use case can navigate to the user interface,
this is not mentioned in the traditional use case model.
2.3. Compound Use Case Restrictions
The compound use case has some restrictions as follows:
The roles should not have relationship to the roles. The
role must have function use relationship to the compound
use cases. The relationship can not exist from the com-
pound use case to the role. The navigate relationship
must exist from the compound use case to the user inter-
face. The relationship between compound use cases must
not be the na vi gate relationship.
The refine relationship means the compound use case
refined does not exist, so if one compound use case is
composed of several use cases, the relationship begin-
ning from this use case must be the refine relationship.
The extend relationship means the compound use case
extended does exist, so if one compound use case is
usecase1
usecase1.1
usecase1.2
usecase1.3
usecase2.1
usecase2.2
usecase2.3
消息2
消息2
消息2
消息2
消息2
消息2
Figure 9. Extend relationship.
Copyright © 2012 SciRes. OJAppS
B. B. XIA, Y. ZHANG
Copyright © 2012 SciRes. OJAppS
183
extended to several use cases, the relationship beginning
from this use case must be the extend relationship.
If there exists non-extend or non-refine relationship
between compound use cases, the next relationship from
the beginning use case of these relationships must not be
extend or refine relationship.
3. Conclusion
The concept of compound use case combines the use
case diagram in the UML object-oriented analysis and
design method, uses in the requirement analysis period
based on the UML object-oriented software engineering
method [7], describes the user requirement of user inter-
face. The compound use case is a character system and
modeling tool. Using the compound use cases, we can
support the whole analysis and design process from user
interface requirement to the final user interface.
4. Acknowledgements
I would like to express my deepest gratitude to TianRui,
who helped me a lot to complete this paper. Second, I
will extend my heartfelt gratitude to teacher Youping
Dong who helped me a lot during my work.
REFERENCES
[1] G. Raghava, “Designing User Interfaces from Use Cases
and Modeling Interface Behaviors with Statecharts [DB/
OL]”. http://www.umlchina.com
[2] S. Egbert, “Model-Based User Interface Software Tools:
Current State of Declarative Models [R],” GVU Tech
Report, Graphics, Visualization and Usability Center,
Georgia Institute of Technology.
[3] N. J. Nunes and J. F. E. Cunha, “Wisdom—A UML Based
Architecture for Interactive Systems [C],” Proceedings of
DSV_IS’2000, Lime r ick, Lecture Notes in Computer Sci-
ence (LNCS), Springer-Verlag, New York, 2000.
[4] N. J. Nunes and J. F. E. Cunha, “Towards a UML Profile
for Interaction Design: The Wisdom Approach [C]. UML
2000—The Unified Modeling Language. Advancing the
Standard,” Proceedings of 3rd International Conference,
York, October 2000, pp. 101-116.
[5] P. P. da Silva and N. W. Paton, “UMLi: The Unified
Modeling Language for Interactive Applications [C]. The
Unified Modeling Language: Advancing the Standard,
3rd International Conference on the Unified Modeling
Language, York, 2-6 October 2000,” In: A. Evans, S.
Kent and B. Selic, Eds., Lecture Notes in Computer Sci-
ence (LNCS), Vol. 1939, Springer, Berlin, 2000, pp. 117-
132.
[6] M. Elkoutbi and R. K. Keller, “User Interface Prototyping
Based on UML Scenarios and High Level Petri Net [R],”
Lecture Notes in Computer Science, Vol. 1825, 2000, pp.
166-184.
[7] J. Vanderdonckt, “Using Data Flow Diagrams for Sup-
porting Task Models[C],” Companion Proceedings of 5th
Eurographics Workshop on Design, Specification, Veri-
fication of Interactive Systems DSV-IS’98, Abingdon, 3-5
June 1998.