2009 IEEE Conference on Commerce and Enterprise Computing
Extending BPMN with Submit/Response-style User Interaction Modeling
Dagmar Auer, Verena Geist
Dirk Draheim
Software Competence Center Hagenberg Hagenberg, Austria {dagmar.auer,verena.geist}@scch.at
Central IT Services Department University of Innsbruck Innsbruck, Austria
[email protected] software engineers concentrating on workflow modeling. So BPMN has the potential to be a common language for both – this has been an important aspect for our choice. However, BPMN is missing support for the modeling of user interaction in the context of the business processes. Analyzing and modeling user interaction is important during the analysis phase, especially when future users are involved, as it offers a way to give an implementation-independent impression on how the new system will support them in their daily work. The second important aspect addressed by our work is the focus on the submit/response-style interaction paradigm. Submit/response-style interaction is the user interface paradigm found in form-based applications ranging from small Web applications to large ERP systems. The clear separation of the client and server state and the defined interaction between these two states proved to be important for the users to understand the interaction process. The semantic clearly defines when the client state and the server state are changed and therefore reduces communication problems between business analysts and users. Experiences from our projects have shown how important it is for users to know exactly at which point in time the client state is submitted to the server. As long as the information is not submitted, the state of the system is only local to the client. Thus, a crucial point of the concept is to explicitly record the submit/response-style interaction in enterprise systems (see Fig. 1).
Abstract—Developing process-oriented enterprise systems not only asks for Business Process Management (BPM) but also for an appropriate user interface and data model. Current BPM and workflow technologies are neither integrated with user dialogs nor offer an appropriate data model. This paper describes a novel integrated framework for modeling processoriented systems called Processes with User Interfaces and Data Modeling Integration (PUDI), which offers a solution to these shortcomings. For the projects described in this paper, we used the Business Process Modeling Notation (BPMN) for the processes, extensions to BPMN for submit/response-style user interaction, which is characteristic of form-based applications ranging from small Web applications to large ERP systems, and the Unified Modeling Language (UML) for the data model which defines both, the information and the message model. The paper discusses related work and describes real-world application scenarios which motivated our research on the proposed framework and illustrates its practical benefits. Keywords: BPMN, dialog modeling, submit/response-style user interaction
I.
INTRODUCTION
Business Process Management (BPM), workflow, etc. are central ideas when planning the development of an enterprise application. In practice projects are often confronted with business analysts and software engineers having different views on the system to be built and using completely different notations and tools. Communication problems are predetermined. The need for a framework to describe a process-oriented enterprise system from different viewpoints and for different target groups arose. Notations and tools need to be suitable for business analysts as well as software developers, especially for models developed during analysis and specification. Current BPM and workflow technologies are not integrated with the user interaction – the dialogs of an enterprise application, and do not offer appropriate integration of the data model. The first important question addressed by our work is how to solve the problem of integrating process modeling with user interaction and data modeling. The Business Process Modeling Notation (BPMN) standardized by the Object Management Group (OMG) has been chosen for “political reasons” as the language to describe business process models by our industry partners. It is a widely used modeling notation for business process analysts as well as
978-0-7695-3755-9/09 $25.00 © 2009 IEEE DOI 10.1109/CEC.2009.75
HTTP Browser
GET hypertext/dir/index.html http/1.0 …Dummy…
PC-Memory PC
CGI
Web Presentation Layer
Application Server Database
Figure 1. Ultra-thin client based submit/response style system [8]
In business projects it is often not possible to introduce another modeling notation for describing user interfaces, as business processes are considered more important [26]. For this reason, we started process modeling with BPMN and extended this modeling notation to support user interactions following the submit/response-style interaction paradigm according to a new methodology called Form-Oriented Analysis.
368
The paper is structured as follows. Section II describes the basis for and the details of our approach to integrate business process modeling with form-oriented user interaction, and data models. Section III gives an overview of related work. Section IV follows with a short description of practical experiences when applying our integrated framework in business projects. Section V gives our conclusions and states open issues. A notational remark: In this paper, standard UML and BPMN notation is used. The reader should be aware of possibly confusing differences between these two notations (e.g., in UML the names of diagrams and modeling elements begin with lower case initials, while in BPMN these names are written with capital initials). II.
the different types of process participants. Swimlanes are used to display external and internal participants, which can be humans, organizational roles/units as well as software components like services or applications. Throughout the intuitive modeling of Activities by Pools and Lanes respectively, basic workflow resource patterns [20] such as Direct Distribution or Role-Based Distribution can be realized straightforward, whereas not all advanced patterns are supported by BPMN. What is missing for our approach is a simple way to describe the general way how users effectively work with applications and factor out actual realization such as data interchange. According to the workflow data patterns [19], the visibility is realized through properties of a Task, a SubProcess or a Process. Interaction issues are supported through the notion of Data Objects associated to Sequence Flows or parameter passing between Sub-Processes. Data transfer is supported via Message Flows, data routing is handled by Data Objects and miscellaneous Event types. However, there is no means of specifying details of data in BPMN 1.1, such as concrete attributes and types, or the relations between data entities, as we are accustomed to do in UML class diagrams. Considering these characteristics, BPMN offers clear semantics for structuring process elements, to specify when and in which order they are performed, who is responsible for them and which informational entities are created or manipulated during the process. What is missing, however, is a clear interface for integrated modeling of user interaction. Like current BPM and workflow technologies, BPMN does not fully integrate the application programs that constitute the dialogs of an enterprise application. This means that BPMN focuses on the process states but not on the dialogs that bridge the process states. Consequently, the dialog states cannot be seen by BPMN users. This leads to a successful use of BPM technology in enterprise application projects in the following sense: rules in the interplay of existing enterprise applications are identified and then automated. On the other hand, if a workflow-intensive system is to be built from scratch with BPM technology, it is not obvious how to design the human/computer interaction. So what we especially need is to describe in detail which information is exchanged between the user and the system. Of course, it is possible to model both system and user as Pools and then use Message Flow and Intermediate Message Events for communication and Data Objects to specify which data is shown to the user and which data is submitted to the system. However, this option is far less readable and intuitive than the concept we propose in this paper.
INTEGRATED BUSINESS PROCESS MODELING USING THE FORM-ORIENTED ANALYSIS
Combining best practices of process-oriented and formbased approaches delivers the key benefit of bridging the gap between the developer’s focus on the system “from inside” and the user’s view “from outside” [28]. So we developed a concept for integrated business process modeling by preserving the principles of BPMN and adapting methods from the Form-Oriented Analysis as needed. A. BPMN Selecting notations for modeling process-oriented enterprise systems is a frequently discussed topic. Available languages for conceptual business process modeling [13] differ in their extent of modeling elements, as well as in the source domains and application areas targeted. In our projects described in Section 4, BPMN was the language of choice of our industry partners, as it enables business analysts to freely design processes and developers to add the necessary technical details afterwards. BPMN also meets the requirement to use a generally accepted notation, which guarantees certain sustainability. In [11] Dave Ings, Program Director in the IBM Software Standards group, refers to BPMN as the leading business process modeling standard for supporting business processes through the entire BPM life cycle. At the time we started to work on the projects, several tools that support the BPMN 1.1 specification were available. The upcoming specification for BPMN 2.0 is going to introduce exchange formats based on XML Metadata Interchange (XMI) and XML Schema (XSD) for process models, which are expected to be used in the future. Hence, industry will migrate towards BPMN, which is thereupon likely to substitute the XML Process Definition Language (XPDL) [11]. In contrast to the comprehensive Unified Modeling Language (UML), BPMN only defines one type of diagram and a basic set of modeling elements. Thus, complex processes are easier to model and better to communicate to customers. Whereas the functional and behavioral aspects (Activities, Gateways, Events) are well represented in BPMN [13], the organizational and informational aspects are partly supported only. Focusing on business processes, BPMN naturally includes a role concept, but it does not distinguish between
B. Formcharts Form-oriented Analysis, a methodology to model formbased applications, gives clear semantics of submit/responsestyle dialogs as typed, bipartite state machines called formcharts [8]. Draheim and Weber adapt well-established basic modeling techniques to achieve a modeling framework optimized for simple Web applications to complex Enterprise Resource Planning (ERP) systems, which are typical representatives of the submit/response-style
369
interaction paradigm. A combination of theoretical achievements and hands-on practical advice makes the methodology a reference work for both, researchers in the areas of software architectures and submit/response-style user interfaces [1] [7] [9], as well as professionals designing and developing enterprise applications. The notation of formcharts is similar to UML, but associated with a graphical user interface [28]. So a page can contain one or more forms. After the user has filled in all required input fields, the data is submitted to the server by a dedicated user action, e.g., clicking on the submit button, which causes a change of the system state (two-staged interaction paradigm). A link denotes a form without input fields. The system reacts to the submission of a form with presenting a new rendered dialog page. The user action can be seen as a method call with a collection of all input fields as parameter list. This two-staged interaction scheme can be represented via a state machine with two kinds of states: providing a page to a user (Client Page) and processing submitted data (Server Action). So formcharts can be seen as bipartite state transition diagrams (see Fig.°2, Client Pages are depicted by ellipses, Server Actions are depicted by rectangles): The system remains in a Client Page until the user triggers a state change. Then, over a transition a Server Action is reached. The system automatically leaves this state and moves to the next Client Page. Depending on the input data, the response of the system to a Server Action can be manifold, which leads to several outgoing edges from a Client Page. The transitions can be annotated with conditions (labeled directed multigraph). Similarly, Server Actions can have multiple incoming transitions, which represent calls to the same method from different Client Pages. When using a modeling product called form storyboard, information on parameters and different types of user interaction can be annotated (refer to [8]). The important aspect is that no technical implementation details, such as appearance or position of fields, affect the analysis level. Form storyboards can be seen as a high-level prototype of a system. They are designed to foster communication between experts of business and IT.
Actions, but go towards coupling to a data model. The layered data model consists of the information model (business objects that make up the server system state) and the message model (data shown on a page and data sent back to the system). An important aspect is that formcharts define signatures for every state using algebraic data types (see [8] for formal definition of syntax and semantics). In terms of Client Pages, the signatures represent the information offered on the page. The information is strictly typed and therefore allows for constraint specification that describes the behavior of the system. So formcharts address the communication between interface designers and software developers. We decided to use formcharts in our concept as we are quite familiar with the form-based approach and have several experiences in applying formcharts in business projects. One of the key benefits of formcharts also experienced by analysts of our industry partners is that they can be easily understood also by non-technicians. At the same time, they provide a formal approach to build an information system model as a submit/response-style system interface, which is related to a layered data model. The added value lies in the explicit representation of the two-staged interaction. Moreover, the idea of formcharts is independent of any notation. C. Data Model A crucial part of both business processes and user interfaces is data. Although BPMN provides the possibility to model data, the use of BPMN 1.1 does not displace the need for languages specialized in system development, such as UML. UML provides a powerful means for modeling data by offering the concept of class diagrams. Therefore, we need to add a proper UML data model that describes a central collection of data objects and their relations to the BPMN process model. The data model basically consists of three modeling elements, which we represent by UML classes with proper stereotypes: A Message denotes a data object that can be displayed within a formchart to indicate which information is presented to a user or is transferred to the server depending on the orientation of the association. A Business Object defines a data object that is responsible for the system’s internal state. A Data Type describes a common type that represents a part of a Message or a Business Object. Since BPMN defines a similar notation for business processes as UML defines for activity diagrams, a simple integration of parts of both technologies into one modeling method is obvious and likely to be supported by common tools.
RegistrationLink
Login
LoginForm
Search
Welcome
SearchResult
ViewBook
RegistrationForm
Registration
D. User Interface Modeling Extensions to BPMN For the use of our PUDI framework in the projects, the basic business processes of an enterprise are modeled in BPMN. To handle increasing system complexity, we defined several levels of abstraction for process modeling using the model decomposition and refinement mechanism of BPMN. The highest level contains core BPMN Processes which are composed of Sub-Processes at lower levels of abstraction. Each level is endued with strict naming conventions and modeling guidelines that prescribe which BPMN elements
Book
AddToCart
ShoppingCart
Figure 2. Formchart specifying a part of a bookstore (based on [8])
Formcharts are a more formal way to specify information systems. They differ from form storyboards in that they use formal constraints and do not depict signatures of Server
370
are allowed to be used and in which context they should appear. The restrictions lead to a better understanding and clear semantics of the diagrams. The lowest level of the process model establishes the connection between process modeling with BPMN and the submit/response-style user interaction modeling following the concept of formcharts. Formchart diagrams are used to present a common picture of the functionality of the system, which can be wellunderstood by both business and technical people, called dialog model. They describe both possible user interactions and messages for the user. To ensure an integrative appearance of the system model, we decided to express formcharts in BPMN. Therefore, we define a BPMN Extension to provide additions to the Activity Model of the Business Process Definition Metamodel (BPDM) concept [15] for BPMN. The main parts of the dialog model are modeling elements derived from the BPMN Simple Activity. These modeling elements are supposed to represent Client Pages and Server Actions. Since we have two different semantics with BPMN and formcharts, we need to adapt formcharts to the specification of BPMN. We decided to mark the modeling elements with the stereotypes Page and Action with following meaning: both nodes are proposed to perform work as it is defined for BPMN Activities. An Activity with the stereotype Page has the objective to show a page to the user, an Activity with stereotype Action is considered as basic system call and executes the given operation. We use textual stereotypes to indicate the distinction of the two newly defined modeling elements because graphically illustrated process markers are unlikely to be supported by common modeling tools. As defined in the form-based approach, a formchart diagram always consists of an alternating sequence of Actions and Pages, whereas a BPMN Start Event leads to a Page and a BPMN End Event is reached via an Action (see example diagram in Fig. 3). The alternation of Actions and Pages must be assured by modeling guidelines. To guarantee the exclusive behavior of the control flow in formcharts, the BPMN Sequence Flows are endued with conditions. Relevant side effects should be documented as additional information to Actions. Additional information about a Page can be screenshots and the description of attributes. A major challenge of enterprise projects is to structure the model of a system in a way so that parts of the system can be viewed from different perspectives, neither losing the overall view nor the interrelationship. This involves a clear understanding of the system, as it is also suggested in [21] [4] [5] [22]. The elements of the data model need to be available in all other models. The dialog model shows what users are able to do with the system and what they will get back from it. In the process model, the functionality of the system is structured in a way that the enterprise profits from the processes. The combination of the process model and the dialog model defines how user interactions can appropriately be used to perform business processes. In doing so, the interface is clearly specified: the concept of formcharts is oriented towards single user support whereas process modeling focuses on assigning tasks to process participants. So the use
of BPMN Swimlanes is only permitted in the process model. The dialog model actually is a huge, flat formchart diagram. Start Login
[register]
[login error]
[login]
Login
RegistrationLink
[registration error]
LoginForm
RegistrationForm
Registration
[login ok]
Start Search
[registration ok] Welcome
SearchResult
[view]
ViewBook
Book
[add] AddToCart
End Shopping Cart
Figure 3. Part of the bookstore in BPMN
To achieve abstraction within the models, we need an appropriate decomposition mechanism. The problem of parallel decomposition of data and functionality has already been addressed by work on structured analysis [18]. We decided to structure the content of the dialog model as reusable parts in separate diagrams and called them Dialogs. In the course of the abstraction process, the problem of how to handle sub-processes with several inputs and outputs arises. Since one runs into problems when designing subdiagrams with only one input and one output for purpose of abstraction, this issue has already been outlined early in literature [3]. As specified in [16], a BPMN Sequence Flow cannot cross the boundary of a BPMN Sub-Process. So, we need a possibility to show where the Sequence Flow leaves a diagram and then restarts on the next diagram. The BPMN specification proposes a Link Intermediate Event to be used as an off-page connector. Following the vision of processes, we defined that each Dialog can have several Start and End Events. So, if there are, e.g., three End Events within a Dialog, there are actually three outgoing transitions from this element at the next higher level of abstraction, each transition representing exactly one concrete end of the Dialog. The transitions should be endued with enabling conditions so that it is clear which transition should be taken as consequence of the End Event. The same is specified for several incoming transitions. So it is possible to reflect functional units of hierarchy within a flat dialog model with no restriction to only one input or output. A transition at a higher level of abstraction can be recovered at a lower level, where its data type is propagated to the higher level. This makes the developed concept more than visual manipulation, it does indeed split up content and display, but also delivers clear semantics up to the highest level of abstraction. III.
RELATED WORK
To extend business process modeling with a means to model submit/response-style user interaction, we studied different existing user interface modeling languages.
371
UML offers several diagrams, which can be used to model user interaction. “Use cases are a means for specifying required usages of a system.” [17] p. 587 Functional requirements of a system can be modeled on a relatively high level by describing the interaction of the user with the system. In the context of our work this means that the user interaction associated with a BPMN task could be modeled with use case diagrams. However, use case diagrams do not meet our requirement to support submit/response-style user interaction and consequently are not suitable for our purpose. UML activity diagrams offer much more details than use case diagrams. Activity diagrams are often used to model business processes (see [13] p. 213) and are similar to BPMN to a great extent. Furthermore, activity diagrams are convenient to define internal processes in more detail, which are, e.g., not documented in use case diagrams. But activity diagrams lack support for submit/response-style interaction, too. Using UML state diagrams to describe formcharts lacks specific semantics of formcharts, which cannot be sufficiently added to UML (see [8] for more details). Furthermore, a number of UML-based description languages exist, concentrating on the user interface layout, e.g., the UML Profile for GUI Layout [2] or the Unified Modeling Language for Interactive Applications (UMLi) [23], [10], which is not the primary focus of our work. There are also languages not based on UML with a strong emphasis on design (layout) and implementation of user interaction, such as the User Interface Markup Language (UIML) [27] or the XML User Interface Language (XUL) [29]. Their purpose is not to model user interaction of submit/response-style systems, but they focus on describing “any user interface in a manner that is device-independent and user interface metaphor independent” [27]. An alternative approach is proposed in [26] based on BPMN and Diamodl [6], a dataflow-oriented visual modeling language for the logic and behavior of a user interface. The basic idea of this work is to augment the established modeling language BPMN to cover tasks by adding information concerning the object life cycle. Trætteberg [26] identifies domain modeling and data as one of the weakest points of BPMN due to its focus on XML. Thus, the data model is described with XML schemas and variables refer to an XML fragment and not to an object of a particular class. To define pre- and post-conditions within the task model, BPMN is extended with annotations. This approach does not particularly support the submit/responsestyle interaction. The technical committee of WS-BPEL Extension for People (BPEL4People), an extension to the Business Process Execution Language (BPEL), a common business process execution language, is pushing the next generation of BPEL4People [14]. Only basic operations for client application interactions with human tasks will be considered in the WS-Human Task Specification, task execution rendering and definition of user interface elements are out of their scope.
IV.
APPLIED STUDY
In the following we describe our experiences with the use of the proposed PUDI framework and application scenarios which let and still lead to changes. One of our projects, which led to the development and the first usage of the framework, was conducted with a logistics application service provider. Their enterprise system addresses supply chain execution and consists of software services for transport management, freightage management, procurement management, etc. The project initially was a refactoring project towards a service-oriented architecture. By the time, re-documentation of the system with a strong focus on business processes integrated with means to model user interactions and data turned out to be an essential precondition for the refactoring. The situation within the enterprise was a typical one: There are two groups of experts, one group of software engineers responsible for the development of the system, and one group of business experts responsible for system analysis with the clients to identify the needed adoptions and extensions to the basic system. However, the problem was that business experts and software engineers had a different view on the system. The business experts model a functional hierarchy oriented towards sales and communicate how the system supports customer’s business tasks. The developers decompose the system into a component hierarchy, map the components to software entities and further decompose those entities. Like the business people they also compose the system components to hierarchies, unfortunately, sometimes with a different result. Furthermore, the business analysts and software engineers use different tools and notations due to their different background. Natural consequences were redundancies, inconsistencies and communication difficulties. The main problem we had to face was how to manage the traceability of changes: If a developer changes some code in a module, he can indeed derive the impact on business processes, but only in terms of the software developer models. For the business experts it is not so easy to understand a code change in terms of their business models. Furthermore, there is an overlap in specified phenomena exactly there, where the two worlds meet, at the level of business processes and beyond. So often the same piece of a business process or data was remodeled with different notations, e.g. Event-Process Chain (EPC) or UML. For this reason we started to develop the proposed framework to overcome the inconsistencies and communication problems due to different notations and tools. The introduction of the dialog model supported both the business experts and software developers to get a common understanding of the functional range of the system. The structuring of the data model into the information model and the message model respectively helped to eliminate inconsistencies in the system documentation on the one hand and familiarized the customers with the system’s user interface on the other hand. The problem of raising system complexity was faced in the process model by techniques like reuse or adaptation of existing functions, which enabled
372
the enterprise to advance their system quickly according to customers’ demands. The use of common integrated modeling notations for all system models further fosters the clear understanding of the system and enables business analysts and software engineers to use one single tool for the documentation. As modeling tool we selected Enterprise Architect [24], which supports UML, BPMN and team-based collaboration at a good cost/performance ratio well-fitting for our project. Due to the positive response of the first adoption of our PUDI framework, we currently refine our approach in a further project with a software development company, which has a large Austrian administrative agency as its key customer. We have a consulting role in this project. The target of the project is to create a more flexible IT infrastructure and IT development process, which allows for rapid changes and enhancements. The project spawns all kinds of stakeholders ranging from business development people over system analysts, IT architects to developers and system administrators. Initially, business processes and IT infrastructure were modeled with the ARIS business process analysis tool and implemented with a database rapid development tool. In the future, TIBCO is going to be used for enterprise application integration purposes and workflow execution. Several questions have to be answered in this project. One of them addresses the appropriate amount of standardization for the processes, e.g., to define the correct granularity of process steps. Another important question is how to model the system dialogs, business processes and data without friction. As there are no standards that address the joint modeling of system dialogs and business processes, we successfully used the PUDI framework for analysis and specification purposes and will continue working on covering the whole life cycle of a process-oriented application. Furthermore, potential risks and benefits of a flexible, adaptive, process-oriented infrastructure have to be estimated. This goes hand in hand with the question how emerging and existing standards and trends in the indicated domain will evolve. V.
An important question to be addressed in the future is how to cover the whole life cycle of a process-oriented application, putting special emphasis on iterative development and maintenance. Another problem which is not addressed by our approach is how to find the right granularity between workflow and dialogs. Even though heuristics do exist [25], it is still a problem that needs further systematic treatment. Currently, we are working on unifying workflow and dialog states to eliminate the granularity problem. ACKNOWLEDGMENT This work was supported by the Austrian COMET Program. REFERENCES [1]
[2]
[3]
[4]
[5]
[6] [7]
[8]
CONCLUSION AND FURTHER WORK
[9]
We have presented an extension to BPMN for describing submit/response-style user interaction. User interaction is modeled with BPMN Activities which are marked with the stereotypes Page and Action. The diagrams follow the formbased approach as it is defined in the Form-Oriented Analysis. The alternation of Pages and Actions is assured through modeling guidelines. Our data model which defines both the information model and the message model is described with UML class diagrams, differentiating the data categories by the stereotypes Business Object, Message and Data Type. Since BPMN and the notation for modeling business processes with UML activity diagrams are similar, BPMN and UML can be easily integrated. In the scope of business projects we used and further developed our approach to show that its application is suitable especially for analysis and specification purposes.
[10]
[11]
[12] [13]
[14]
373
S. Balbo, D. Draheim, C. Lutteroth and G. Weber, “Appropriateness of User Interfaces to Tasks,” Proc. International Workshop on Task Models and Diagrams for User Interface Design – For Work and Beyond (TAMODIA 2005), ACM Press, 2005. K. Blankenhorn and W. Walter, „Extending UML to GUI Modeling,“ in Mensch & Computer 2004: Allgegenwärtige Interaktion, R.KeilSlawik, H. Selke and G. Szwillus, Eds., München: Oldenburg Verlag, 2004, pp. 307-308. C. Boehm and G. Jacopini, “Computational linguistics – flow diagrams, turing machines and languages with only two formation rules,” Communications of the ACM, vol. 9, 1966. M. Broy, M. Feilkas, J. Grünbauer, A. Gruler, A. Harhurin, J. Hartmann, B. Penzenstadler, B. Schätz and D. Wild, „Umfassendes Architekturmodell für das Engineering eingebetteter Softwareintensiver Systeme. Modellierungstheorien und Architekturebenen,“ Technical Report, Technical University of Munich, 2008. M. Broy and B. Rumpe, „Modulare hierarchische Modellierung als Grundlage der Software- und Systementwicklung,“ Informatik Spektrum, Springer, 2006. Diamodl home page, http://www.idi.ntnu.no/~hal/research/diamodl. D. Draheim, C. Lutteroth and G. Weber, “Robust Content Creation with Form-Oriented User Interfaces,” Proc. International Conference of the ACM's Special Interest Group on Computer-Human Interaction (CHINZ 2005), ACM International Conference Proceeding Series, vol. 94, ACM Press, 2005. D. Draheim and G. Weber, “Form-Oriented Analysis – A New Methodology to Model Form-Based Applications,” Springer-Verlag, 2005. D. Draheim and G. Weber, “Modelling Form-Based Interfaces with Bipartite State Machines,” Journal Interacting with Computers, vol. 17, no. 2, Elsevier, 2005, pp. 207-228. Rolf Hennicker and Nora Koch, “Modeling the User Interface of Web Applicatons with UML,” Practical UML-Based Rigorous Development Methods – Countering or Integrating the eXtremists, Workshop of the pUML-Group (UML 2001), Gesellschaft für Informatik, 2001. D. Ings, M. Das and I. Trickovic, “BPMN 2.0 Virtual Roundtable Interview,” 2008, http://www.infoq.com/articles/bpmn2;jsessionid=96E87713854B377427AFAC025FE5BF4F. C. Kecher, „UML 2.0: Das umfassende Handbuch,“ Bonn: Galileo Press, 2006. B. List and B. Korherr, “An Evaluation of Conceptual Business Process Modelling Languages,” Proc. ACM symposium on Applied computing, 2006. OASIS; “WS-BPEL Extension for People (BPEL4People) Technical Committee,” http://www.oasisopen.org/committees/bpel4people/charter.php.
[15] Object Management Group, “Business Process Definition MetaModel (BPDM) Beta 1”, OMG Adopted Specification, OMG Document No. dtc/07-07-01, 2007. [16] Object Management Group, “Business Process Modeling Notation V1.1,” OMG Adopted Specification, OMG Document No. formal/2008-01-17, 2008. [17] Object Management Group, “UML 2.2 Superstructure Specification,” OMG Document No. formal/2009-02-02, 2009, http://www.omg.org/cgi-bin/doc?formal/09-02-03. [18] D. T. Ross, “Structured analysis (sa): A language for communicating ideas,” IEEE Transactions on Software Engineering SE-3, 1977. [19] N. Russell, A.H.M. ter Hofstede, D. Edmond and W.M.P. van der Aalst, “Workflow Data Patterns,” QUT Technical Report, FIT-TR2004-01, Brisbane: Queensland University of Technology, 2004. [20] N. Russell, A.H.M. ter Hofstede, D. Edmond and W.M.P. van der Aalst, “Workflow Resource Patterns,” BETA Working Paper Series, WP 127, Eindhoven: Eindhoven University of Technology, 2004. [21] A.-W. Scheer, “Aris - Business Process Modeling,” Springer, 2000. [22] P. Schubert, R. Wölfle and W. Dettling, “E-Business-Integration. Fallstudien zur Optimierung elektronischer Geschäftsprozesse,“ Hanser, 2003.
[23] P. P. da Silva and N. W. Paton, “User Interface Modeling in UMLi,” IEEE Software, 2003. [24] SparxSystems: “Enterprise Architect - Product Information,” 2009, http://www.sparxsystems.com/products/ea.html. [25] B. Stegmaier, M. Ebbers and T. Begovac, “Image and Workflow Library: FlowMark V2.3 Design Guidelines,” IBM International Technical Support Organization, 1998. [26] H. Trætteberg, “UI Design without a Task Modeling Language – Using BPMN and Diamodl for Task Modeling and Dialog Design,” Proc. Conference on Human-Centered Software Engineering and International Workshop on Task Models and Diagrams (HCSE/TAMODIA), IFIP International Federation for Information Processing, 2008, pp.110-117. [27] User Interface Markup Language, http://www.uiml.org/. [28] O. Weiß, “Integrated System Modelling Using the Form-Oriented Analysis – Focusing SOA- and Model-Driven Techniques on Simple System Usage,” VDM Verlag Dr. Müller, 2008. [29] XML User Interface Language (XUL), http://www.mozilla.org/projects/xul/.
374
