An artifact-centric approach to generating web-based
business process driven user interfaces
Citation for published version (APA):
Yongchareon, S., Liu, C., Zhao, X., & Xu, J. (2010). An artifact-centric approach to generating web-based business process driven user interfaces. In L. Chen, & P. Traintafillou (Eds.), Proceedings of Web information systems engineering - WISE 2010 : 11th international conference, Hong Kong, China, December 14-14, 2010 (pp. 419-427). (Lecture Notes in Computer Science; Vol. 6488). Springer. https://doi.org/10.1007/978-3-642-17616-6_38
DOI:
10.1007/978-3-642-17616-6_38
Document status and date: Published: 01/01/2010 Document Version:
Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers) Please check the document version of this publication:
• A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website.
• The final author version and the galley proof are versions of the publication after peer review.
• The final published version features the final layout of the paper including the volume, issue and page numbers.
Link to publication
General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain
• You may freely distribute the URL identifying the publication in the public portal.
If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement:
www.tue.nl/taverne Take down policy
If you believe that this document breaches copyright please contact us at: openaccess@tue.nl
providing details and we will investigate your claim.
L. Chen, P. Triantafillou, and T. Suel (Eds.): WISE 2010, LNCS 6488, pp. 419–427, 2010. © Springer-Verlag Berlin Heidelberg 2010
Business Process Driven User Interfaces
Sira Yongchareon, Chengfei Liu, Xiaohui Zhao, and Jiajie XuFaculty 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
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 algorithmsThe 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.
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,
422 S. Yongchareon et al.
− 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 : C u s t o me r c req u est s t o ma k e a n Ord e r o
C on d i t i on i n st a t e (o, i n it ) ∧ ¬d e f in e d (o .ord e rID) ∧ ¬d e f i n ed (o . c u s to me r ID) ∧ d e f i ne d (c . c u s to me r ID)
Ac t i on c r e a t e Ord e r(c , o ), c h s t a t e (o , o pe n _f o r_ it e m)
r2 : Ad d Ord e rIt e m o i of Pro d uc t p wi t h a qu a n ti t y q t y t o Ord e r o
C on d i t i on i n st a t e (o, o pe n _f o r_ it e m) ∧ i n st a t e (o i , i n i t ) ∧ d ef i n ed (p . p rod uc t ID) ∧
d e f i ne d (o i .p ro du c t ID) ∧¬d ef in e d (o i .o rd e rID) ∧ d e f in e d (o i. qt y ) ∧ ¬ d e f i ne d (o i .p ri c e ) Ac t i on a d d It e m(o , oi , p ), c h s t a t e (o , o pe n _f o r_ it e m), c h s ta t e (o i , n e w l y_ ad d ed ) r3 : C omp l et e Ord e r o C on d i t i on i n st a t e (o, o pe n _f o r_ it e m) ∧ o .g ra n d To t a l > 0 Ac t i on c o mp l e t e Ord e r(o ), c h s t a t e (o , re a d y_ fo r_ sh ip p in g ) r4 : Pa y In v o i c e v for Ord e r o
C on d i t i on i n st a t e (o, b i ll e d ) ∧ i n sta t e (v , un p a id ) ∧ d e f in e d (v . o rd e r ID) ∧
o . o rd e rID = v . o r d e r ID ∧ o .g ra n d Tot a l = v .a mo un t Pa id
Ac t i on p a y In vo i c e (v , o ), ch st a t e (v , p ai d )
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 scorrespond-ingle 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
424 S. Yongchareon et al.
−
∆
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 relatransi-tion ⊆ × 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
426 S. Yongchareon et al.
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 web-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)
