An artifact centric approach to generating web-based business process driven user interfaces

An Artifact-Centric Approach to Generating Web-Based
Business Process Driven User Interfaces

Sira Yongchareon, Chengfei Liu, Xiaohui Zhao, and Jiajie Xu

Faculty of Information and Communication Technologies
Swinburne University of Technology
Melbourne, Victoria, Australia
{syongchareon,cliu,xzhao,jxu}@swin.edu.au

Abstract. Workflow-based web applications are important in workflow man-
agement systems as they interact with users of business processes. With the
Model-driven approach, user interfaces (UIs) of these applications can be par-
tially generated based on functional and data requirements obtained from under-
lying process models. In traditional activity-centric modelling approaches, data
models and relationships between tasks and data are not clearly defined in the
process model; thus, it is left to UI modellers to manually identify data re-
quirement in generated UIs. We observed that artifact-centric approaches can be
applied to address the above problems. However, it brings in challenges to au-
tomatically generate UIs due to the declarative manner of describing the
processes. In this paper, we propose a model-based automatic UI generation
framework with related algorithms for deriving UIs from process models.

1 Introduction
Over the past several years, the use of workflow management system in organizations
has been considered as a promising automation approach to enable them to design,
execute, monitor and control their business processes. It is conceived that current
workflow technologies support organization’s own developed web applications for
users to efficiently interact with the processes they involve. The interaction of users
and these workflow-based applications are through user interfaces (UIs) that are de-
signed and developed when workflows are modelled. This can bring an issue of cou-
pled alignment between business processes and UIs, i.e., changes of the processes that
impact on UIs are to be managed in an ad-hoc manner [9]. Several works [9-12] have
been proposed the adoption of Model Driven Approach (MDA) that specify the asso-
ciation between models that support the propagating changes and control the align-
ment of business processes and UIs of underlying applications.
Traditionally, business processes are modelled by identifying units of work to be
done and how these works can be carried out to achieve a particular business goal.
This approach, so called activity-centric business process modelling, has been recog-
nized as a traditional way of process modelling and it has also been used in many
MDA approaches, e.g., in OOWS-navigational model [12], for the semi-automatic
generation of UIs by deriving task-based models from business process models. These

L. Chen, P. Triantafillou, and T. Suel (Eds.): WISE 2010, LNCS 6488, pp. 419–427, 2010.
© Springer-Verlag Berlin Heidelberg 2010

420 S. Yongchareon et al.

approaches require UI modellers to know information that is needed to be inputted
from users and then to manually assign it to corresponding UIs. Thus, the changes of
the data requirements of any task are still not able to reflect to the UIs if the process
changes, so a better approach is required.
We observed the traditional approaches of business process modelling and found
that they have some drawbacks and are limited to support only partially automatic UI
derivation. Especially, the data model and task model are defined independently and
their relation may not be coherently captured in the activity-centric model. In addi-
tion, as the limitation of the model, the current derivation approaches can provide
only one-to-one transformation, i.e., one task to one page of UI. A mechanism to
combine multiple tasks to fit within a single page without losing control or breaking
the integrity of the process, e.g. transaction, is not supported. To this end, we consider
a new paradigm of process modelling called artifact-centric approach [1-4].
By using the artifact-centric approach, UIs can be automatically generated from
business processes by deriving both behavioural aspect (navigational control flow
relations between UIs) and informational aspect (related/required data in each UI)
from the underlying processes. In this paper, we propose a web-based business proc-
ess driven user interface framework. It comprises two models, Artifact-Centric Busi-
ness Process (ACP) model and User Interface Flow (UIF) model, and a mechanism to
derive UIF model from ACP model. The UIF model describes the constitution of UIs
and their navigational control flows which can be derived from the underlying ACP
model. In summary, our work makes the following contributions to the research in
business process modelling and web engineering areas:
• Analyze the relations between artifact-centric web-based processes and UIs
• Facilitate the UIs derivation for processes with UIF models and algorithms
The remainder of this paper is organized as follows. Section 2 provides the formal
model for artifact-centric business processes. Section 3 presents the approach for UIF
model generation. Section 4 reviews the related works. Finally, the concluding re-
marks are given in Section 5 together with our future work.

2 Artifact-Centric Business Process Models
The concept of modelling artifact-centric processes has been established under the
framework proposed in [4] with the formal model [5]. Our artifact-centric business
process model (ACP model) extends their work. The model consists of three core
constructs: artifacts, services, and business rules. An artifact is a business entity or an
object involved in business process(es). A service is a task that requires input data
from artifact(s) or users, and produces an output by performing an update on
artifact(s). A business rule is used to associate service(s) with artifact(s) alike in a
Condition-Action-Role style. To explain the model, we use a retailer business scenario
consisting of two business processes: product ordering and shipping. The ordering
process starts when a customer places an order to the retailer for a particular product
and ends when the customer pays the invoice. The shipping process starts when the
retailer creates a shipment and ends when the item arrives to the customer.

An Artifact-Centric Approach to Generating Web-Based Business Process Driven UIs 421

Figure 1 illustrates artifact lifecycle diagram of each artifact used in our business
processes. We denote l.v[m.s] for the transition to be triggered by a performer with
role l invokes service v if artifact m is in state s.

Fig. 1. Lifecycle diagram of each artifact used within our business scenario

2.1 Syntax and Components of ACP Model

Definition 1: (Artifact class). An artifact class abstracts a group of artifacts with
their data attributes and states. An artifact class C is a tuple (A, S) where,
− A = { , , …, }, ∈A(1≤i≤x) is an attribute of a scalar-typed value (string
and real number) or undefined value
− S = { , , …, }∪{ } is a finite set of states, where denotes initial state

Definition 2: (Artifact schema). An artifact schema contains a set of artifact
classes, i.e., = , ,…, where ∈ (1≤i≤n) is an artifact class.
From our business scenario, we define a primary set of artifact classes as below.
− Order = ({orderID, customerID, grandTotal}, {open_for_item,
ready_for_shipping, in_shipping, shipped, billed, closed})
− Shipment = ({shipID, customerID, shipDate, shipCost}, {open_for_shipitem,
ready_to_dispatch, in_shipping, completed})
− OrderItem = ({orderID, productID, shipID, qty, price}, {newly_added, on_hold,
ready_to_ship, added_to_shipment, in_shipping, shipped})
− Invoice = ({invoiceID, ordereID, invoiceDate, amountPaid}, {unpaid, paid})

We also define two predicates over schema (1) defined(C, a) if the value of attribute
a∈C.A in artifact of class C is defined and (2) instate(C, s) if the current state of arti-
fact of class C is s, where s∈C.S
Definition 3: (Service). A service or task provides a particular function. A service
may involve with several artifacts of classes , , …, , where ∈ (1≤i≤y).
Definition 4: (Business Rule). A business rule regulates which service can be per-
formed by whom, under what condition, and how artifacts’ states change accordingly.
Rule r can be defined as tuple (c, v, ) where,


− c is a conditional statement defined by a quantifier-free first-order logic formula (
only AND connective (∧) and variables are allowed).
− v∈V is a service to be invoked, and v can be nil if no service is required
− is a set of transition functions where = , , …, }, each ∈ (1≤i≤y)
denotes a function chstate(C, s) to assign the state s∈C.S to the current state of an
artifact of class C
Table 1 lists some business rules in our business scenario.

Table 1. Examples of business rules

r1 : Customer c requests to ma ke an Order o
Condition instate(o, init) ∧ ¬defined(o.orderID) ∧ ¬defined(o.customerID) ∧
defined(c.customerID)
Action createOrder(c, o),
chstate(o, open_for_item)
r2: Add OrderItem oi of Product p with a quantity qty to Order o
Condition instate(o, open_for_item) ∧ instate(oi, init) ∧ defined(p.productID) ∧
defined(oi.productID) ∧ ¬defined(oi.orderID) ∧ defined(oi.qty) ∧ ¬
defined(oi.price)
Action addItem(o, oi, p),
chstate(o, open_for_item), chstate(oi, newly_added)
r3: Complete Order o
Condition instate(o, open_for_item) ∧ o.grandTotal > 0
Action completeOrder(o),
chstate(o, ready_for_shipping)
r4: Pa y Invoice v for Order o
Condition instate(o, billed) ∧ instate(v, unpaid) ∧ defined(v.orderID) ∧
o.orderID = v.orderID ∧ o.grandTotal = v.amountPaid
Action payInvoice(v, o), chstate(v, paid)

2.2 Artifact System for Artifact-Centric Processes

In this section we define artifact system as the operational model for capturing the
behavior of artifact-centric processes. The artifact system is modeled by adopting the
concept of state machine for describing behaviors of objects in a system [6].
Definition 5: (Artifact Machine). An artifact machine defines state transitions of an
artifact class. An artifact machine m for an artifact of class C can be defined as tuple
(S, , T), where S is a set of states of C, ∈S is the initial state, and T⊆ S × V
× G × S is a 4-ary relation of a set of states S, services V, and guards G. A transition t
= ( , v, g, )∈T means that the state of the artifact will change from to if ser-
vice v is invoked and condition g holds.
Definition 6: (Artifact System). An artifact system is a tuple ( , V, R, M) where
is an artifact schema, V and R are sets of services and business rules over , respec-
tively, and M is a set of artifact machines, each for a class in .


For an artifact class C∈ , given service set V and rule set R, its artifact machine
m∈M can be generated by deriving from corresponding business rules that are used to
induce state transitions of C.

3 User Interface Flow Model Generation
In this section, we formally describe the constructs in User Interface Flow Model
(UIF model), and propose an approach to derive UIF models from underlying artifact-
centric process models. The model comprises (1) a set of web pages and (2) relations
between these pages. A page may contain a single or multiple input forms. Each form
contains input fields that user must fill in data to make a form completed. There are
two abstract aspects of the UIF models: behavioural aspect (navigational control flow
relations between UIs) and informational aspect (related/required data for each UI).

Fig. 2. (a) UIF Model, (b) UIC with an interface and its required attributes of artifacts

Figure 2 shows the components and structure of the UIF model. The round-rectangle
depicts a User Interface Container (UIC), which represents a single web page of UIs.
An Interface represents a form comprising a set of required attributes of correspond-
ing artifact that is used in the form. A single UIC may contain either empty interface
(for the final or initial UIC), or a single or multiple interfaces (for normal UIC). The
Navigational Control Flow (NCF) is used to indicate that once the interface with all
required data has been submitted, then the action, e.g., service, corresponding to such
interface is performed and the following UIC then becomes active. The UIF starts at
the initial UIC and terminates when it reaches the final UIC.

3.1 Syntax of UIF Model

Definition 7: (Interface). An interface represents a form of web page. It contains a
required set of attributes of artifact, as well as a role of users and a corresponding
service that will be invoked if users complete the form. Let b denote an interface and
it is defined as tuple (O, , ∆, v), where
− O⊆ , is a finite set of artifact classes used in the interface
− ⊆ . is a required attribute set, which can be inputted/edited by users


− ∆ defines a set of current states of each artifact of class in O when they are in the
interface b, i.e., ∀ ∈∆,∃ ∈O, ∃ ∈ .S, such that instate( , ). We use to
denote the state of artifact of class .
− v∈V is a corresponding service which can be performed after attributes in are
all completed by users

Note that an interface may contain nothing, called empty interface, where O, , ∆ = ∅
and v = nil. It is only used in the initial and the final UICs.
Definition 8: (User interface Flow Model or UIF Model). The UIF model, denoted
as , represents UI components and their relations, and it is tuple (∑, Ω, B, F) where,
− ∑ = {ε , ε , …, ε }, ε ∈∑ (1≤i≤x) is a UIC
− B = { , , …, }∪{ }, ∈B (1≤i≤z) is an interface, where denotes an
empty interface
− Ω ⊆ ∑ × B defines the relation between UICs and interfaces
− F ⊆ Ω × ∑ is a finite set of Navigational Control Flow (NCF) relations. A flow f
= ((ε , ), ε ) ∈ F corresponds to a NCF relation between the source UIC ε and
the target UIC ε , such that when ε is active and every attribute in of interface
is completed then ε is enabled (activated) and ε is disabled (deactivated).
According to two aspects of the UIF model, the behavioral aspect is represented by
its UIs components and their NCF relations, while the informational aspect is
represented by internal information of artifacts required for each interface. Once we
defined ACP and UIF models, then the next step is to derive UIF models from under-
lying ACP models. Two main steps are required: (1) generating the interfaces and
their NCF relations for constructing the behavior of the model and (2) mapping the
required artifacts and their attributes for constructing the information for each inter-
face. These steps are described in Section 3.2 and 3.3, respectively.

3.2 Constructing the Behavior of UIF Models

Every machine in the system is required to be composed into a single machine as to
generate the entire behavior of the system, i.e., behavioural aspect of UIF models
according to the control logic of underlying business processes. In this section we
define artifact machine system for the completed composition of all machines in the
artifact system by adapting the compositional technique presented in [6].
Definition 9: (Artifact system machine). Let denote the result machine
generated by combining artifact machine and machine . For an artifact system
with machine set M for its artifacts, the combined artifact machine, i.e., , is
called artifact system machine. Combined machine = =( , , ),
where set of states ⊆ .S × .S, initial state =( . , . , transi-
tion relation ⊆ ×V× × , and is guards, such that contains no refer-
ences to states in and .


Fig. 3. The behavioral aspect of UIF model

After completing the composition for artifact system machine, we need to process
a mapping from such machine to the UIF model. The mapping contains two steps: (1)
states to UICs mapping and transitions to interfaces mapping. (2) NCF relation gener-
ation. There can be multiple interfaces in a single UIC if such state has multiple exit
transitions. The result of mapping shows the behavioral aspect of the model. Figure 3
shows the result of applying this mapping to our business processes.

3.3 Mapping Information of Artifacts to Interfaces

Once we completed behavioral aspect mapping of UIF model, then we need to gener-
ate its informational aspect by assigning artifacts onto interfaces. In this step, we need
to find all the corresponding artifacts required for each interface. We can classify the
information needs for a particular interface into: (1) a set of artifacts to be read or
updated, and (2) a set of required values to be assigned to attributes of such artifacts.
We can simply find both sets by extracting them from every condition of business
rules that corresponds to a service to be invoked of such interface. Note that the re-
quired attribute set and artifacts for each interface are minimal and sufficient. They
can be extended if users would like to incorporate other related artifacts by adding
them into the interface; however, these additional artifacts need to be validated as to
ensure that the behaviour consistency between UIF and ACP models is preserved.
Here, we can say that our proposed information mapping explicitly overcomes the
drawbacks of current approaches in which activities, data and their relation are treated
separately.

4 Related Work and Discussion
In the context of business process modelling, Küster Ryndina, & Gall [7] established
a notion of business process model compliance with an object life cycle. They also
proposed a technique for generating a compliant business process model from a set of
given reference object life cycles in forms of state machines. Redding et al. [8] con-
ducted a similar work, where they proposed the transformation from objects behavior
model to process model by using the heuristic net for capturing the casual relations in


the object model. Compared with our work, their transformations use an object beha-
vior model as input, while our work uses the artifact process models. In addition,
these approaches are different from ours in such way that they do not consider state
dependency between artifacts but we do.
In the area of web engineering in user interfaces, both Sousa et al. [9] and Sukavi-
riya et al. [10] presented a model-driven approach to link and manage software re-
quirements with business processes and UI models. With their approaches, a process
model is mapped to a UI model, thus change propagation can be managed more effi-
ciently. Guerrero et al. [11] and Torres et al. [12] applied the similar concept for de-
veloping UIs corresponding to workflow models. All these approaches considered
traditional activity-centric process models and proposed approaches to define the
internal components and functionalities of the UIs at different levels, e.g., task-base
model, abstract UI, and concrete UI. In comparison with these approaches, we consi-
dered the artifact-centric model to capture data requirements and their relation with
tasks, and propose an automatic generation framework to provide a highly-cohesive
bridge between the operational back-end system of business processes and the front-
end UI system. The generated UIs can be further customized by UI modelers without
a concern of the integrity of business logic. Moreover, changes of data requirement
that specified in the model can be reflected on UIs.

5 Conclusion and Future Work
This paper has proposed a model-based automatic UI generation framework for web-
based business processes based on artifact-centric process modeling approach. In the
framework, the ACP model and the UIF model are defined with a mechanism to de-
rive the UIF model from the ACP model. The UIF models reflect the logic of business
processes and intuitively represent what information is required during the processes.
In the future, we plan to improve the model for supporting wider user interface re-
quirements e.g., optional data elements, role-based configuration.

References
1. Nigam, A., Caswell, N.S.: Business artifacts: An approach to operational specification.
IBM Syst. J. 42(3), 428–445 (2003)
2. Liu, R., Bhattacharya, K., Wu, F.: Modeling Business Contexture and Behavior Using
Business Artifacts. In: Krogstie, J., Opdahl, A.L., Sindre, G. (eds.) CAiSE 2007 and WES
2007. LNCS, vol. 4495, pp. 324–339. Springer, Heidelberg (2007)
3. Bhattacharya, K., et al.: Artifact-centered operational modeling: Lessons from customer
engagements. IBM Systems Journal, 703–721 (2007)
4. Hull, R.: Artifact-Centric Business Process Models: Brief Survey of Research Results and
Challenges. In: Meersman, R., Tari, Z. (eds.) OTM 2008, Part I. LNCS, vol. 5331, pp.
1152–1163. Springer, Heidelberg (2008)
5. Bhattacharya, K., et al.: Towards Formal Analysis of Artifact-Centric Business Process
Models. In: Alonso, G., Dadam, P., Rosemann, M. (eds.) BPM 2007. LNCS, vol. 4714,
pp. 288–304. Springer, Heidelberg (2007)


6. Lind-Nielsen, J., et al.: Verification of Large State/Event Systems Using Compositionality
and Dependency Analysis. Formal Methods in System Design 18(1), 5–23 (2001)
7. Küster, J., Ryndina, K., Gall, H.: Generation of Business Process Models for Object Life
Cycle Compliance. In: Alonso, G., Dadam, P., Rosemann, M. (eds.) BPM 2007. LNCS,
vol. 4714, pp. 165–181. Springer, Heidelberg (2007)
8. Redding, G., et al.: Generating business process models from object behavior models. In-
formation Systems Management 25(4), 319–331 (2008)
9. Sousa, K., et al.: User interface derivation from business processes: A model-driven ap-
proach for organizational engineering. In: ACM SAC 2008, pp. 553–560 (2008)
10. Sukaviriya, N., et al.: Model-driven approach for managing human interface design life
cycle. In: Engels, G., Opdyke, B., Schmidt, D.C., Weil, F. (eds.) MODELS 2007. LNCS,
vol. 4735, pp. 226–240. Springer, Heidelberg (2007)
11. Guerrero, J., et al.: Modeling User Interfaces to Workflow Information Systems. In: ICAS
2008 (2008)
12. Torres, V., Pelechano, V.: Building Business Process Driven Web Applications. In: Dust-
dar, S., Fiadeiro, J.L., Sheth, A.P. (eds.) BPM 2006. LNCS, vol. 4102, pp. 322–337.
Springer, Heidelberg (2006)

An artifact centric approach to generating web-based business process driven user interfaces

More Related Content

Similar to An artifact centric approach to generating web-based business process driven user interfaces (20)

More from Dr. Sira Yongchareon (6)

Recently uploaded (20)

An artifact centric approach to generating web-based business process driven user interfaces