INSTRUCTION FILE

February 13, 2012 12:43 WSPC/INSTRUCTION FILE

ModelFramework

Integrated Framework for Seamless Modeling of Business and Technical Aspects in Process-Oriented Enterprise Applications

Dirk Draheim IT Service Management Division University of Innsbruck Innsbruck, Austria [email protected] Verena Geist and Christine Natschl¨ ager Software Competence Center Hagenberg GmbH Hagenberg, Austria {verena.geist,christine.natschlaeger}@scch.at Received (3rd November 2009) Revised (27th July 2010) Revised (24th January 2012) Accepted (8th February 2012) The different views and modeling techniques of both the business analysts and software developers are a common problem in business process modeling. Various modeling approaches result in communication problems, as well as redundancies and inconsistencies in system documentation. Thus, when modeling process-oriented enterprise applications seamless support of both expert groups is necessary. However, current business process management and workflow technologies are not fully integrated with user interaction, nor do they offer an appropriate data model. Based on the requirements of two industrial projects, we developed an integrated framework that combines the best practices from process-oriented and form-based approaches to overcome these shortcomings. The described framework supports the submit/response-style interaction paradigm and is independent of modeling languages and tools. In this work, we will present a detailed description of the proposed framework, its application to an industrial project and a discussion of related work. Keywords: Business Process Modeling, Process-Oriented Enterprise Applications, User Interaction Modeling, BPMN

1. Introduction Business Process Management (BPM) is an established [1, 2] concept in the development of enterprise applications. In many process-oriented modeling projects, business analysts and software developers work together closely; however, they often have different views and use various modeling languages. This is problematic for system documentation because communication problems, redundancies and inconsistencies emerge. The different views and modeling languages are thus a fundamental problem in many process-oriented modeling projects because they are likely 1


ModelFramework

2

to increase the occurrence of gaps or overlaps in the system documentation, leading to difficulties regarding the adaption of software due to customer requirements for forward change requests or requests for entirely new functionality, the flexibility of the IT infrastructure or the development process that should allow for rapid changes and enhancements. Therefore, our basic research question is: ”How can we achieve seamless documentation between business analysts and software developers in process-oriented modeling projects?” We have studied the problem of seamless documentation within two industrial projects (a third project is in its initial phase) and developed a modeling method based on the submit/response-style interaction paradigm and formcharts [3]. The resulting modeling framework consists of the following four models: • Process Model: Describes the business processes of the enterprise • Dialog Model: Describes possible user interactions and messages • Technical Model: Describes the technical refinement of the system by a close-to-implementation representation of the system’s functional range • Data Model: Describes a central collection of business objects (logical representation of physical databases) and their relations Our approach will be presented in detail in the following manner: a problem description is given in Section 2; Section 3 contains essential modeling guidelines and introduces the new modeling approach with a detailed description; Section 4 presents a discussion of the selected modeling languages and tools for our modeling method; Section 5 describes a case study executed in a concrete project; Section 6 reports related work; and conclusions are presented in Section 7. 2. Problem Description A common problem in many process-oriented modeling projects is that business analysts and software developers are accustomed to different modeling approaches, languages and tools. These various perspectives can lead to communication problems, as well as gaps or overlaps in documentation. This problem existed in two of our industrial projects. We therefore developed a new approach for seamless documentation that is currently being used in a third project. In the first project, customers wanted to move towards a Service-Oriented Architecture (SOA). However, it soon became clear that business process redocumentation efforts would be advantageous. In this project, the developed software is sold to several customers and therefore has to be adapted in most cases. A business analyst has to collect the customers’ requirements and forward change requests or requests for entirely new functionality to the software development team. In a second project, we consulted a software development company whose primary customer is a large Austrian administrative agency. For this project, we had to create a more flexible IT infrastructure and development process that would allow for rapid changes and enhancements.


ModelFramework

3

Fig. 1. Typical structural inconsistencies in a combined business process and system model

At the moment, the developed approach is being used in a third project, which is executed on behalf of a social insurance company. Concerning business process development, the situation in all of these projects is typical. There are two groups of experts: software developers responsible for system development and business analysts responsible for designing and adapting the software based on the customers’ needs. The problem is that business analysts and software developers view the system differently, yet their respective group behaviors are always the same. Fig. 1 shows a system with an observable behavior made of system dialogs. The business analysts model a functional hierarchy that is oriented towards selling the system and communicating how the system supports business tasks for the user. The developers decompose the system dialogs into a component hierarchy to deal with complexity (i.e., they map the actions of the dialogs to software entities and further decompose those software entities). In addition, similar to the business analysts, they compose dialogs resulting in hierarchies. However, these hierarchies may differ from those created by analysts because developers are driven by technical issues. Due to their backgrounds, the different groups use different tools and languages, as shown in Fig. 1. The business analysts use Event-driven Process Chains (EPCs) [4], task models [5], and function trees [6] as diagrams and Visio, Word and MindMap as tools. The software developers use Unified Modeling Language (UML) activity diagrams, UML class diagrams and EPCs (to a certain extent) as diagrams,


ModelFramework

4

Fig. 2. Mitigating structural inconsistencies in a combined business process and system model

as well as Word and ER/Studio as tools. For this reason, models of the same system evolve in different languages and tools, which can lead to documentation gaps when looking at all models as a whole. This gap can be seen in Fig. 1 in the box which displays the system dialogs. The mentioned problem can also be described from the perspective of traceability. If a developer changes code in one module, she/he can derive the impact on business processes but only in terms of the technical models. However, for business analysts it is difficult to understand the impact of the code change on their business models. Furthermore, in some scenarios there is an overlap where the two worlds meet, at the level of business processes and beyond. As such, the same part of a business process sometimes has to be modeled with EPCs by a business analyst and as a UML activity diagram by a software developer. This causes inconsistencies in the system documentation and communication problems between the two groups. In summary, the problem in our process-oriented modeling projects is not the quality of the models or the system description; it is the notational and tool heterogeneity. The proposed framework addresses this problem. Our goal was to select a canonical set of modeling languages, in particular to select as few different languages as necessary and to choose a single modeling tool for all models and system descriptions (Fig. 2). Furthermore, it was necessary to provide a style guide for seamless modeling without the above described documentation gap.


ModelFramework

5

3. Modeling Guidelines and Model Construction The basic concept of our approach is independent of any modeling language or tool; however, it was necessary to choose languages for the specific projects. In addition to the technical aspects, user acceptance was important and therefore the stakeholders’ expectations and attitudes had to be respected. We selected Business Process Modeling Notation (BPMN) [7] for business process modeling and the Unified Modeling Language (UML) [8] for system development (see Section 4). The major challenge was to structure the functionality of the system in a convenient way so that parts of the system could be viewed from different perspectives without losing the overall view and the interrelationships. This requirement was solved by identifying four models, each one for a specific domain of the functional range of the system [9]. The models are further structured into several levels of abstraction. In addition to a clear delimitation of the models, it is necessary to achieve connectivity between the hierarchically designed models. We address this issue by specifying different levels of abstraction with their modeling attributes and describing how to get from one model or level to the next. Another main topic is the formation of a business process diagram hierarchy. In the course of the abstraction process, the question of how to handle sub-processes with several inputs and outputs arose. One gets into trouble when designing sub-diagrams with only one input and one output for the purpose of abstraction. This issue has already been outlined in the literature, e.g. in [10]. System documentation is often a central part of an enterprise. Our research revealed that a sufficient model of an application needs to be composed of several models. In fact, four necessary models were identified to guarantee seamless support of business and technical aspects in the documentation of process-oriented enterprise applications: Process Model, Dialog Model, Technical Model and Data Model. All models together describe the current state of the system. Fig. 3, which is supposed to provide both business and technical experts an overview of the system documentation, illustrates the ”Big Picture” of the modeling method based on the four models. The primary questions that should be answered are the following: • • • • •

Which content belongs to which model? What level of detail is appropriate for each model? What is the right level of abstraction? Which language is used at each level? Which modeling elements are allowed?

Structuring the system according to these four models provides a clear understanding of the system. Moreover, techniques like reuse or adaptation of existing functions allow quick development of enterprise applications according to customers’ demands. The following suggestions and guidelines are also intended to aid the decision about what information should be documented, in which model and at what level of abstraction.


ModelFramework

6

Fig. 3. ”Big Picture” of the four Models

During our industrial projects, we identified several guidelines that are related to the modeling of processes, dialogs, data and technical aspects. Process modeling guidelines provide an appropriate decomposition mechanism to deal with system documentation complexities. Guidelines for modeling dialogs and associated data are based on formcharts. This means that the Human-Computer Interaction (HCI) is form-oriented; it consists of an ongoing interchange of report presentations and form submissions (i.e., users invoke an action on the server and get a report and a form (a page) as a response on which they can invoke new actions). In addition, we developed guidelines on the basis of BPMN that must be adhered to in the Process Model, the Dialog Model and the Technical Model. The guidelines are adjusted to the developed modeling method; however, they are still compliant with the BPMN specification, which is intended to be extensible [7]. In the same way, we defined guidelines for modeling with UML concerning data and technical aspects. Attention should be paid to which BPMN elements are allowed to be used at which level of a model (cf. Fig. 3). Restrictions lead to better understanding and clear semantics of the diagrams. Hierarchical structuring is only intended for the Sub-Process and UI Group elements, as well as the levels of the Technical Model.


ModelFramework

7

3.1. Process Modeling The Process Model aims to communicate the functional range and the main business processes of the system to customers, as well as sales and marketing personnel. However, the Process Model does not specify how a process is performed by a user nor does it define how discrete activities are realized. To achieve abstraction within the process model, an appropriate decomposition mechanism is necessary. The problem of parallel decomposition of data and function has already been addressed by work on structured analysis [11]. The modeling notation we use to model processes is BPMN. Abstraction in BPMN is designed similarly to UML activity diagrams and groups elements that belong together. A feasible approach for structuring the Process Model is to define a set of business processes and sub-processes for every business domain of the enterprise. The abstraction levels of the Process Model are based on BPMN Activities with defined stereotypes for Business Domain, Business Process, Sub-Process and Business Task. As specified in [7], a Sequence Flow cannot cross the boundary of a BPMN Activity that represents a Sub-Process, so it is necessary to show where the Sequence Flow leaves a diagram and then restarts on the next diagram. We define that each diagram can have several Start and End Events (e.g., if there are three End Events within a BPMN Activity, then there are three outgoing transitions from this element at the next higher level of abstraction, each transition representing exactly one concrete end). The transitions should be endued with enabling conditions to determine which transition should be taken as a consequence of the End Event. Similar to outgoing transitions, enabling conditions are determined for several incoming transitions of the Start Event of the Sub-Process. If the Sub-Process would only display one input and one output at a higher level of abstraction then information would be lost. In summary, if there is a transition between BPMN Activities at a higher level of abstraction, this transition can also be found at the lowest level of abstraction [3]. Fig. 4 displays the transitions in different levels of abstraction and shows how a hierarchical structure is built. In the bottom region of the figure, four Business Tasks (D, E, F, G) are displayed, building a sequential list. These Business Tasks are summarized to Sub-Processes (D & E − > B and F & G − > C ). The transition between E and F is essential and is illustrated as a connection between B and C. In a last step, the two Sub-Processes are further summarized as Business Process A. This scenario is also displayed as a flat model in Fig. 5. Thus, the developed abstraction concept provides more than a means of visual manipulation; it splits up content and views while also delivering a clear semantic up to the highest level of abstraction. Although this concept may sound trivial, it is essential for seamless process and dialog modeling. On one hand, Dialogs are defined in flat diagrams with off-page connectors connecting elements on the same level but in different diagrams (Section 3.2). On the other hand, Dialogs are defined underneath Business Tasks and therefore are also connected with the Process Model.


ModelFramework

8

Fig. 4. Hierarchical Structure of a Business Process

Fig. 5. Flat Model of the Business Process with Boundaries and Transitions

Regarding Fig. 3, the defined levels can be used as modeling elements at higher levels of abstraction (e.g., Business Tasks can be used on the Sub-Process and Business Process levels). The Business Process and Sub-Process levels provide modeling elements for classical business process modeling. Thus, it is possible to specify Swimlanes (BPMN Pools and Lanes) for self-contained entities as well as for internal roles. This leads to an appropriate structuring within the Dialog Model that only supports single-user scenarios. The lowest level, and thus the smallest unit of the Process Model, is the Business Task. The Business Task serves as a wrapper for user interactions (Actions, Pages) and whole user dialogs (Dialogs) of the Dialog Model. Business Tasks establish the connection between the Process Model and the Technical Model by wrapping technical aspects (Services, Interfaces, and Operations). In addition, a connection between the Dialog Model and the Technical Model can be established by refining Actions.


ModelFramework

9

3.2. Dialog Modeling The Dialog Model of the system documentation describes possible user interactions and messages for the user. This model associates business analysts with software developers by presenting a common picture of the current functional range of the system. The main task of the Dialog Model is to define what a user can do with the system and which responses she/he will receive. Technical information, such as which services are triggered by user interactions or how an action is technically realized, does not belong in this model. The Dialog Model is based on concepts described by form-oriented analysis [3]. Form-oriented analysis gives clear semantics of submit/response-style dialogs as typed, bipartite state machines called formcharts [3]. The user interacts with the system within a sequence of interchanging client and server states. In the client state, information is presented to the user and several options for entering and submitting data are offered. The dialog changes to a server state when the user submits data. In the server state, the submitted data is processed and depending on the current server system state, the generation of a new client page is triggered (i.e., the server state is left automatically). Submitting data is therefore similar to calling a method, the data being a parameter [3]. A formchart consists of client pages, server actions and the transitions between them. Fig. 6 shows a formchart that models the dialog of a bookstore [3]. In the formchart, client states are depicted by ellipses, server states are depicted by rectangles and transitions are depicted by arrows. The submit/response-style interaction paradigm, a user interface paradigm found in form-based applications, clearly separates the client and server states and defines the interactions between the states. Experiences in our projects have shown that it is very important for the users to know exactly when the client state is submitted to the server. Thus, a concept to explicitly record the submit/responsestyle interaction in enterprise applications is necessary. The advantages of the formoriented analysis are that the approach is independent of any language, and the diagrams are easy to read, even for business analysts. In addition, the concept includes an explicit representation of two-staged interaction and provides a formal means to develop a submit/response-style system interface for form-based applications. Similar to the Process Model, the abstraction levels of the Dialog Model are based on BPMN Activities. They are endued with the stereotypes for Business Domain, UI Group and Dialog. Again, the levels can be used as modeling elements at respective higher levels of abstraction. The Business Domain and UI Group levels do not provide modeling elements for the definition of a process and hence compose a hierarchical structure across the flat Dialog Model. The levels do not define semantics for the sequences below; instead they support the concept of abstraction. The lowest level and thus the smallest unit of the Dialog Model is the Dialog. Dialogs do not contain further Dialogs or higher levels of abstraction as modeling elements. For report generation, Dialogs must remain readable and must not contain


ModelFramework

10

Fig. 6. Formchart Example

too many details. The use of BPMN Pools and Lanes is not permitted within the Dialog Model because the concept of modeling form-based applications is oriented towards single user support. Swimlanes as modeling elements are only intended for technical refinement or for modeling role concepts in processes. The two main modeling elements of a Dialog are the BPMN Activities Action and Page with the homonymous stereotypes. A diagram always consists of an alternating sequence of Actions and Pages, with BPMN Start Events leading to Pages and BPMN End Events being reached via Actions. Pages are seen as abstractions of real (Web) sites and can have additional information like screenshots and descriptions of their attributes. Pages with similar functionality are merged into one Page. Actions are considered as elementary system calls. Relevant side effects of an Action should be documented as additional information to the Action. If an Action consists of complex sequences, the Action can be refined within the Technical Model. The content of every Dialog is represented as a separate diagram. To support the modeling method with commonly used modeling tools, a concept to inform the selected tool that one specific End Event of a Dialog corresponds to exactly one Start Event of another Dialog is needed. The BPMN specification proposes a Link Intermediate Event to be used as an off-page connector. Hence, all Start and End Events that represent a connection to another diagram are displayed as Intermediate Events. In addition, we add a note to every off-page connector, which specifies the name of the corresponding page. Due to appropriate structuring, parts of the Dialog Model that are frequently needed within the system can be reused easily. An example is the documentation of the navigation menu in one of our industrial projects. In this project, similar functionality is extracted from several pages and documented in one diagram that describes the navigation possibilities within the system.


ModelFramework

11

3.3. Technical Modeling The Technical Model of the system documentation describes the technical refinement of the system by a close-to-implementation representation of the system’s functional range. This model includes detailed descriptions of the technical realization of user interactions from the Dialog Model as well as the concrete implementation of services or interfaces. Thus, it forms the basis of the Process Model and the Dialog Model and supports the modeling language UML and the notation BPMN. At the beginning of the refinement, BPMN can be used for modeling; however, for detailed technical documentation, UML is recommended. For the BPMN Activities and UML elements that form the levels of abstraction of the Technical Model, the stereotypes for Module, Service, Interface, Action and Operation are assigned. (Web) services and interfaces are elements that are frequently needed during documentation of the system, and thus particular stereotypes are introduced for them. In addition to the user interactions (Actions), the Technical Model contains a set of system operations. In general, these operations are attached to the stereotype for the Operation. All of these modeling elements are integrated into Modules and can be refined to an arbitrary level of detail; however, the depth of modeling should be limited. 3.4. Data Modeling The Data Model of the system documentation describes a central collection of UML and BPMN elements with specific stereotypes, i.e. Business Objects, Data Types, Messages, Data Objects, and their relations. Business Objects are a logical representation of physical databases as UML classes and have an essential influence on the system’s state. Messages are only used within the Dialog Model and are exchanged with the users at the system border. Business Objects and Messages, although not directly connected, are somehow linked because Messages comprise a subset of attributes defined within Business Objects. A reasonable approach for organizing elements with regard to reusability is to split Business Objects into common Data Types. Data Types can be used similarly for displaying Messages for system users. The connection between Data Types and Business Objects or Messages is made by associations. BPMN Data Objects are used to explicitly displaying input and output data of processes within the Process Model. Data Objects are related to Business Objects using the same name; however, Data Objects do not define any attributes. Data Objects provide additional information about the process but do not have an effect on the process flow. Modification of the data can be visualized by specifying their states in squared brackets. 3.5. Delimitation of the Models The models were developed based on the content they present. Data is needed anywhere within the model of a system, so the vertical alignment of the Data Model


ModelFramework

12

Fig. 7. Information Content of the Horizontal Aligned Models

in Fig. 3 implies that specific elements are available for all other models through all levels of abstraction. Modeling workflows is more difficult as many miscellaneous perspectives and levels of abstraction are needed. Thus, the representation of the horizontally-aligned models, which are the Process Model, the Dialog Model and the Technical Model, starting at different vertical positions, reflects the different information content of the models. Increasing information content can be illustrated as a pyramid (Fig. 7). This representation helps model developers decide which data should be documented in with each model, based on the defined information content. The pyramid only contains the model parts that are highlighted in gray in Fig. 3 because displaying all the models in terms of information content would form a multidimensional pyramid. Above these main parts of the models, it was necessary to build higher levels of abstraction. As a result, the levels of the Process Model, Dialog Model and Technical Model overlap in Fig. 3; however, they do not contain redundant information. 3.6. Seamlessness of the Models In addition to the delimitation of the models regarding the placement of information, another essential aspect is the connection between the models, which provides a seamless model of the system. In Fig. 3, the seamlessness among the models is indicated with two continuous lines; the first lines connects the Process Model, Dialog Model and Technical Model (line above Dialog and under Business Task and Module). The Business Task of the Process Model serves as a wrapper for user dialogs and interactions of the Dialog Model and technical aspects of the Technical Model using the aggregation principle. The second line connects the Dialog Model to the Technical Model (line under Dialog and above Level n). The Technical Model, with its descriptions of concrete realizations, forms the basis of the two other models. Fig. 8 displays the seamlessness of the system model by explicitly representing the models and their relationships. The system is accessed by user interactions or external events. User interactions apply to the Dialog Model (a), whereas events can trigger processes of the Process Model (b). The relationship between the Process


ModelFramework

13

Fig. 8. Seamlessness of Models

Model and the Dialog Model (c) defines how user interactions within the Dialog Model can be used appropriately within business processes. The connection between the Dialog Model and the Technical Model (d), as well as the connection between the Process Model and the Technical Model (e), determine where refinement of user interactions and processes should occur, from a technical point of view. There are also connections between the Data Model and all other models (f, g, h) because specific elements of the Data Model are available in all other models through all levels of abstraction. The Dialog Model forms the business logic of the system (Fig. 8). Therefore, the definition of modeling elements in this model is essential for subsequent report generation. Information that should be available for each element are pre-condition(s), process description, result(s), post-condition(s) and exception handling measures (optional). In addition, the Technical Model forms the basis of the Process Model and the Dialog Model. The integrated approach provides seamless support of both expert groups. Business analysts are responsible for servicing the Process Model, starting at the level of the Business Domain and going via the Business Process and the Sub-Process to the Business Task (cf. Fig. 3). Software developers define the Technical Model in terms of Modules, Services, Interfaces, Actions and Operations to a certain level of detail. The common basis of both is the Dialog Model. Dialogs consisting of Actions and Pages are developed by both business analysts and software developers and thus build the prerequisite for mutual understanding. The Data Model also provides shared modeling elements, i.e., business analysts rather use Data Objects, whereas software developers primarily use Messages, Data Types and Business Objects. The diagrams taken from the case study (Section 5) demonstrate the seamlessness of the models and the levels of abstraction.


ModelFramework

14

4. Modeling Languages and Tools With respect to user acceptance concerning the stakeholders’ expectations and the technical aspects, we selected Business Process Modeling Notation (BPMN) [7] for business process modeling and the Unified Modeling Language (UML) [8] for system development. BPMN 1.0 was published as the Object Management Group (OMG) Standard in 2006. Its target users are business analysts. The current version is BPMN 1.2, which has been available since the beginning of 2009, and BPMN 2.0 is being developed. BPMN is a process-oriented notation, first the control and data flow are modeled and afterwards the object model is developed. BPMN can be used by business analysts and IT architects to collaboratively design, deploy and monitor business processes. An advantage of BPMN is the possibility to map designed processes directly to the Business Process Execution Language (BPEL). In contrast to the comprehensive UML, BPMN only defines one type of diagram – the Business Process Diagram (BPD) – and supports fewer modeling elements. The core set of BPMN elements are Flow Objects (Events, Activities and Gateways), Connecting Objects (Sequence Flows, Message Flows and Associations), Swimlanes (Pools and Lanes) and Artifacts (Data Objects, Text Annotations and Groups). Thus, complex processes are easier to model and understand. The use of BPMN does not eliminate the need for system development languages, such as the UML. UML is a relatively open standard, controlled by the OMG and strongly aligned with the needs of software architects and developers supporting technical processes. UML is an object-oriented language, first the necessary objects are identified and then dynamic behavior is defined. The integration of UML and BPMN into one standardized modeling method is relatively easy because there are several similarities between them (e.g., BPMN defines a similar notation for business processes as UML defines for activity diagrams, both are suitable for modeling processes and both are maintained by the OMG). The added value arises from the combination of process- and object-oriented paradigms. BPMN was approved by the business analysts and software developers of our industrial partners. The business analysts endorse the use of BPMN because the notational element set resembles those of EPCs, which was the primary modeling technique they had been using, and the notation allows for freely designing processes. Software developers endorse the use of BPMN because the notation allows them to add the necessary technical details to business processes, and it fulfills their requirement for a generally accepted notation with certain sustainability. The already used and well-known modeling language UML was also accepted by the software developers. We further extended BPMN to express formcharts (Fig. 9). This extension provides additions to the Activity Model of the Business Process Definition Metamodel (BPDM) concept [12]. The semantics of BPMN and formcharts are different, so formcharts are adapted to BPMN specifications. The modeling elements Page and Action of formcharts are defined as BPMN Activities with textual stereotypes Page and Action. The modeling element Page represents a dialog or


ModelFramework

15

Fig. 9. Formchart expressed in BPMN

page shown to the user, whereas the modeling element Action stands for a basic system call and executes a given operation. The diagram further consists of an alternating sequence of Actions and Pages with BPMN Start Events leading to Pages and BPMN End Events being reached via Actions. The alternation is assured by modeling guidelines. Lastly, the control flow in formcharts is expressed via BPMN Sequence Flows that are endued with conditions [9]. The common modeling tool chosen for our projects was Enterprise Architect by SparxSystems, which supports UML 2.1, BPMN 1.1 and team-based collaboration at low costs with good performance. Development environments like Microsoft Visual Studio and Eclipse, as well as technologies like the Zachman Framework [13], TOGAF, and BPMN (version 1.1), are available with additional Add-Ins. We chose the Enterprise Architect for our projects because the selected modeling language UML and notation BPMN, as well as a comprehensive set of technologies, are supported. Another modeling tool is provided within the scope of ARIS [4]. The ARIS Toolset is a commercial product that has been developed by the IDS Scheer GmbH


ModelFramework

16

since 1992 and was overtaken by the Software AG in 2009. It consists of several modules and components for modeling, publishing, simulation, process cost estimation, reporting and configuration. However, similar to the ARIS enterprise framework, the ARIS Toolset aims at the whole business and not at single software projects. TIBCO Business Studio allows developers to model, deploy and manage business processes and is the design environment for TIBCO’s business process management and service-oriented architecture platforms. It is based on the development environment Eclipse and supports the modeling language XPDL and notation BPMN. TIBCO Business Studio is not used in our projects because fewer development environments, and hardly any technologies, are supported. The IBM Rational System Architect, formerly owned by Telelogic, is an enterprise architecture and business process analysis tool that supports frameworks like the Zachman Framework, TOGAF, DoDAF and MODAF, as well as UML and BPMN. In addition, System Architect offers support for team collaboration by providing a variety of user interfaces with a common data repository. However, we do not use System Architect in our projects because the licensing fees are much higher than those of Enterprise Architect. Another enterprise process modeling tool is the Modeling Suite by Mega, which provides a business process analysis tool, modeling tools and design environments. Modeling Suite can be used to define several kinds of diagrams, such as business process diagrams and UML diagrams. A meta-model that is inspired by BPMN describes all concepts, objects and relationships and can be customized for specific users’ needs [14]. However, the licensing fees of Modeling Suite are approximately five times higher than those of Enterprise Architect and, at the moment, only the development environment Microsoft Visual Studio is supported [15].

5. Case Study The motivation for the development of an integrated modeling framework that seamlessly supports business and technical aspects of process-oriented enterprise applications is derived from two industrial projects. The projects were conducted with a leading Austrian IT provider for supply chain execution systems [16] and with a software development company that has a large Austrian administrative agency as its key customer. Within these projects, the basics for the proposed framework were developed. In the first project, for example, the modeling was done within three three-day workshops by six practitioners divided into three groups each consisting of a business analyst and a software developer, resulting in about 200 business functions. However, since the processes of the two projects are confidential, we decided to demonstrate the framework on the basis of another industrial project conducted within the accident prevention domain of the Austrian Social Insurance Company for Occupational Risks (AUVA). The goal of the prevention domain is to suggest measures to improve the employees’ safety and health conditions at their workplaces. Since the prevention workers have to visit the companies, an important workflow is business travel processing. In the original project, the process was


ModelFramework

17

described textually and by a matrix defining the initial and target states. Furthermore, dialogs and their order were sketched in a small prototype, technical aspects were specified by several UML diagrams (e.g., use case, class or sequence diagrams) and the data model was provided in the form of an entity-relationship model. All these models and many further ones specifying other processes have been defined by up to 10 software developers who worked for about four years in this project. The business travel process was also investigated in [17] to identify issues in modeling, and a BPMN model was defined. All in all, the models were sufficient to successfully complete the project. However, the following issues emerged: • Changing Effort: Changing models is time-consuming and error-prone because dependent models must be identified and adapted as well. Furthermore, changes are not traceable. • Inconsistency: Due to the changing effort, not all dependent models were updated regularly, resulting in inconsistencies. • Incompleteness: Some aspects were not defined in sufficient detail within the design phase, e.g., no dialogs were defined for a business task or a technical description was missing. • Complexity: Modeling is in some cases too complex to be done by a business analyst. For example, it is unlikely that a business analyst can develop a prototype comprising the dialogs. • Tool Heterogeneity: The models were defined using different tools. This makes maintenance and versioning difficult. In the case study, the business travel process is modeled based on the suggested framework resulting in integrated models. Hence, the benefits of this approach are: • Change Support: Models are defined in a hierarchical structure, thereby connecting dependent models so that changes can be performed easily. • Consistency: The provided change support increases consistency. Furthermore, whenever an element is completely removed, the refined models are deleted as well. • Stepwise Refinement: The model is stepwise refined resulting in a clear documentation. • Collaboration: The approach supports collaboration of the business analysts and software developers. • Completeness: Elements without a plus sign are no more refined and may easily be identified. The expert can then decide whether a detailed description is necessary or not. • Single Tool: All models can (and should) be defined in one tool, e.g. Enterprise Architect. Thus, only one tool must be installed, all elements have the same appearance and the models can easily be maintained and versioned. • Sufficient Information: The presented approach provides the most relevant models in a compact form.


ModelFramework

18

Fig. 10. Process Model: Business Domain Level

Fig. 11. Process Model: Business Process Level

Although modeling based on the integrated framework does not guarantee consistency, completeness or sufficient information, it nevertheless provides the foundation to reach those goals. However, the modeling guidelines and policies described in Section 3 must be considered. We will now present the case study in detail. The presented figures, taken from the constructed Process Model, Dialog Model, Technical Model and Data Model, aim to show the central integration aspects of the case study. In the AUVA project, we have one main solution called AUVA Prevention, which corresponds to the element called Business Domain of our Process Model (Fig. 10). This Business Domain is identical to the highest level of abstraction of the Dialog Model. According to the structuring of the Process Model, the next lower level contains the basic processes of AUVA Prevention, shown as Business Processes in Fig. 11. Descending the hierarchy, Fig. 12 describes the main process flow in the form of BPMN Start/End Events, Gateways and Business Tasks for the Business Process Business Travel Processing. In this case study, there is no need to model SubProcesses because the process steps are sufficiently granular. We now take a look at the Business Task Send for Approval to demonstrate how integration of modeling elements in different models is realized. Behind a Business Task, relations to the Dialog Model via single Actions/Pages or whole Dialogs can exist. Also, relations to the Technical Model via Services, Interfaces or simple Operations are allowed. In this example, the Send for Approval Business Task wraps the homonymous Dialog Send for Approval (Fig. 13), which can be reached by clicking on the Business Task in Fig. 12. Thus, we have made a seamless transition from the Process Model to the Dialog Model. The Dialog Model defines the same Business Domain as the top-level element of the Process Model (Fig. 10). However, the Business Domain AUVA Prevention is now divided into several modeling elements that denote modules on the user interface. For this reason, they are modeled as UI Groups (Fig. 14). The UI Group Activity Management includes user interfaces for carrying out business travel re-


ModelFramework

19

Fig. 12. Process Model: Business Task Level

Fig. 13. Integration Process Model – Dialog Model: Dialog Level

Fig. 14. Dialog Model: UI Group Level

quests and the Dialog Send for Approval (Fig. 15). We start with the Dialog Business Travel Overview to show the various user interactions necessary for creating a business travel request, especially the task of sending the request for approval. When refining the Dialog Business Travel Overview one can see a part of the Dialog Model, which represents a flat diagram with an alternating sequence of Pages and Actions. Fig. 16 shows an entry point from which we can reach the Page Business Travel Overview. From this Page there are a variety of possible Actions that can be taken, depending on the user’s choice. One of them is to send the


ModelFramework

20

Fig. 15. Dialog Model: Dialog Level

Fig. 16. Dialog Model: Action/Page Level (1)

business travel request for approval. The corresponding sequence (Fig. 17) is reached via an Intermediate Event that represents an off-page connector for portioning large diagrams. The rather small Dialog consists of one Page followed by an Action; however, a detailed definition of data used for the Action, Send Business Travel, is given within the Message. The Business Process determines a fixed sequence of Actions and Pages of the Dialog Model, which must be undertaken to perform the process in the right way, by arranging corresponding Business Tasks (Fig. 12). Thus the Dialog Model at the level of Action/Page shows what users are able to do with the system and what they will get in return for each action. In the Process Model, however, the functionality of the system is structured so that an enterprise profits from the process. Most of the system functionality, discussed so far, could be sufficiently described within the Dialog Model. However, some Actions might be complex and may need to be documented in more detail. In Fig. 16 these Actions are indicated by a plus sign within the BPMN Activity. This establishes a seamless connection from the


ModelFramework

21

Fig. 17. Dialog Model: Action/Page Level (2)

Fig. 18. Integration Dialog Model – Technical Model: Operation Level

Dialog Model to the Technical Model. We take the Action, Close Business Travel, as example, which defines a simple Operation of the same name (Fig. 18) that clarifies its technical sequence. The Operation, Close Business Travel, is defined within the Technical Model as part of the Module, Business Travel Management. A suitable representation for the Operation is a UML sequence diagram that clearly shows the communication between the user, the client and the server (Fig. 19). The Data Model in Fig. 20 shows all relevant Business Objects, common Data Types and their relations for performing a business travel requests (considering only significant attributes and their types). Data elements are essential for describing all models of a system; therefore, the integration of the Data Model and all other models is a crucial task. Our integration approach is shown in the case study as follows: • Integration of the Data Model and the Dialog Model is done by Messages (Fig. 17), which are linked to the corresponding Business Object(s) by selected attributes. Furthermore, Data Types represent a part of both Messages and Business Objects. • Integration of the Data Model and the Process Model is based on a domain model. In business processes, data is often only roughly specified. Therefore,


ModelFramework

22

Fig. 19. Technical Model: Sequence Diagram Level

Fig. 20. Data Model

we used BPMN Data Objects in Business Processes (Fig. 12) that can be compared to domain entities. This helps to identify the essential Business Objects of the Data Model. • Integration of the Data Model and the Technical Model is easy to realize by using Business Objects in UML diagrams that describe technical details (Fig. 19).


ModelFramework

23

As we have argued in this section, the projects in the case study are amenable to show that the targeted exploitation of the suggested framework can lead to improved change support, artifact consistency and completeness, stepwise refinement, collaboration between stakeholders, and team efficiency. The statements stem from a necessarily qualitative analysis [18] of the projects’ proceedings, due to the lack of generally accepted formal measurements for a sufficient quantitative analysis [19] of the considered variables. We argue in favor for the evidence of the statements on observed benefits by the following facts: (i) scientific accuracy of the projects, (ii) high internal quality management standards in the projects and (iii) overall success of the projects. The projects have not been pure industrial projects but were mixed industrial and scientific projects, enabled by significant grants from the Austrian research foundation FFG (Forschungsförderungsgesellschaft). Actually, the practical, i.e., industrial value creating activities, were accompanied by significant time and efforts for scientific reflection, analysis and discussion. These scientific efforts were continuously intertwined with the systematic planning and enforcement of the projects’ SCRUM-based software process. This means that feedback by team members from both the customers and our expert teams have been continuously gathered and analyzed. Similarly, feedback from the projects’ owners has been ensured by the establishment of appropriate steering committees. Furthermore, as a whole both projects have been ranked as successful by both the customers and our research company, for example, the described AUVA project has been awarded 2nd place in the GC-GENIUS 2009 (innovation award of the Austrian healthcare cluster) research and development award.

6. Related Work Traetteberg [20] presents an approach for modeling business applications using BPMN, XML, XML schema and Diamodl, which is a hybrid dialog modeling language based on interconnected abstract interaction objects, UML class/object diagrams and statecharts [21]. While BPMN is used for process and task modeling, the UI structure and behavior are designed with Diamodl. The author identifies domain modeling and data as weak points of BPMN and therefore uses XML and XML schema for the data model. To define pre- and post-conditions within the task model, the author extends BPMN with annotations. Similar to our approach, Traetteberg identified the necessity of an integrated process, dialog, and data model. However, no technical models are provided and the approach does not consider the submit/response-style interaction pattern. The goal of the Unified Enterprise Modeling Language UEML [22] is to support the integrated use of enterprise and information system models expressed in different languages. According to [23], 130 constructs from 10 languages have already been mapped into the UEML ontology, among these languages are BPMN and selected diagram types of UML 2.0. Nevertheless, no language is yet fully validated. UEML could not be used in our projects because development of the necessary modeling


ModelFramework

24

language UML and notation BPMN has not been finished. UEML might be an interesting and helpful language in the future. The Zachman Framework [13] consists of six rows for the viewpoints (Scope, Enterprise (or Business) Model, System Model, Technology Model, Detailed Representations, and Functioning Enterprise) and six columns for the aspects (Data, Function, Network, People, Time, and Motivation). The aspect Data includes the logical and physical data model, the data definition, and the actual data. Considering all six viewpoints, it is similar to our Data Model described in Section 3.4. In addition, the six viewpoints reflect the abstraction levels in our approach. The aspect Function contains the Business Process Model and is similar to our Process Model described in Section 3.1. However, missing are detailed descriptions of user interactions and technical aspects. The business process framework Architecture of Integrated Information Systems (ARIS) was developed by August-Wilhelm Scheer and consists of five views. The views are symbolically presented in the form of a house, the so-called ARIS house with the Organization View as the roof, the Data, Control, and Function View as the three pillars, and the Output View as basis of the house [4, 24]. A detailed comparison between ARIS and our approach is not meaningful because ARIS is a framework for overall enterprise architecture, whereas our approach aims at enterprise applications in the domain of software engineering. Nevertheless, two views of the ARIS concept are similar to our approach. The Function View supports goals and defines processing rules for application software. According to [24], the designations ”function”, ”process” and ”activity” are used synonymously, thus this view is similar to our Process Model. In addition, the Data View comprises the data processing environment, as well as the messages triggering functions, and is therefore similar to our Data Model. The Open Group Architecture Framework (TOGAF) [25] was developed by The Open Group Architecture Forum and has been maintained since 1995. TOGAF is based on the Technical Architecture Framework for Information Management (TAFIM) from the US Department of Defense. Similar to ARIS, TOGAF aims at overall enterprise architecture and therefore introduces four related types of architecture: Business (or Business Process), Data, Applications, and Technology Architecture. The Business Architecture defines the business strategy, governance, organization, and key business processes and is, although on a higher level, similar to our Process Model. The Data Architecture describes the structure of an organization’s logical and physical data assets and data management resources and thus has some similarities with our Data Model. Enterprise architecture frameworks [26] like the Zachman Framework, ARIS and TOGAF bring systematization to the plethora of models, or more generally to the plethora of artifacts, that show up during the life-time of the IT system of an enterprise. Beyond this, a concrete tool that supports a concrete enterprise architecture framework may explicitly or implicitly define balancing rules between several kinds of artifacts managed by this tool. Such balancing rules target, e.g.,


ModelFramework

25

the unique naming and renaming of modeling elements and the unique place of definition of a modeling element. Similarly, concrete tools offer traceability features, which are simply a means to materialize the conceptual relationships between the elements of several kinds of artifacts managed by a concrete enterprise architecture tool. However, the enterprise architecture frameworks do not elaborate domainspecific guidelines for concrete models or artifacts. The relationship between the mature, product-line oriented, enterprise application modeling approach KobrA [27] and its currently emerging multi-dimensional modeling tools is yet another example of the relationship between enterprise application frameworks and supporting tools [28, 29]. Against the background of this described relationship, the approach presented in this article can be characterized as orthogonal to enterprise architecture framework approaches. It concentrates on the development and maintenance of process-oriented (i.e., workflow-intensive) IT systems and proposes specific guidelines for this application domain. The views that are defined in our approach show up naturally and are provided to reduce complexity. However, the domain-specific elaboration of our approach goes beyond the definition of the views; the views only provide the framework for the modeling guidelines. The more concrete guidelines, e.g., the bipartiteness of the submit/response-style dialogs that are considered by our approach or the concrete elaboration of process model hierarchies, can also be re-used or re-elaborated in the realm of other enterprise architecture frameworks. The approach presented in this article resembles enterprise architecture frameworks with respect to the views it defines. In a sense, with its views it defines a reductionist domain-specific enterprise architecture framework but it does not claim and does not aim to be a fully-fledged enterprise architecture framework in its own right. Our framework is not an enterprise architecture framework as Zachman, ARIS and others. We think that enterprise architecture frameworks are generic proposals of how to analyze or document an enterprise system landscape. ARIS is such a description framework but also proposes concrete, own artifacts for the several framework components, albeit not merely, i.e., in the ARIS tool set more than hundred artifact types are managed – much more than the artifact types proposed and described genuinely as ARIS artifact types. In that sense the general structure of our framework, i.e., our framework minus the concrete artifact types we propose, could also be considered or, to say it better, misunderstood as an enterprise architecture framework. Our framework was neither intended nor designed as such and obviously lacks important enterprise dimension for this purpose. Similar to our approach, the work by Weiss in [30] also discusses a concrete set of artifacts for modeling an information system by exploiting formcharts as crucial artifacts for system dialog models. Superficially, the approaches differ with respect to notational issues. For example, UML activity diagrams are used to express dialogs, whereas in our work BPMN is used for this purpose. However, the crucial difference between the two approaches is the way the methods are designed. Our approach is to build an apparatus from scratch, whereas the work in [30] integrates form-oriented concepts and diagram types into an existing model-driven software


ModelFramework

26

engineering framework. As a result our approach is more focused on the specific domain of workflow-intensive systems. The goal of the approach presented in [31, 32] is to provide an integrated model for conceptually designing both databases and user interfaces. The user interface of a data-intensive information system basically consists of a collection of dialogs using defined procedures for accessing the underlying databases. The guiding idea stems from object-orientation, following the object-action principle in the field of interfaces, i.e., the user selects an object on a screen and invokes actions on that object in order to change data in the database and navigate to the next dialog object. The proposed approach exploits object-orientation [33] and hence is a general and particular mature approach, whereas the notion of form-oriented systems that underlies the presented framework is primarily specializing in two-staged interaction and therefore rather domain-specific. Considering dialog modeling, the User Interface Markup Language (UIML) [34] is a declarative XML-compliant meta-language for describing user interfaces. The design objective of UIML is to provide a vendor-neutral, platform-independent, canonical representation of any user interface. The Unified Modeling Language for Interactive Applications (UMLi) [35] extends UML to provide greater support for UI design, but is restricted to form-based user interfaces. The XML User Interface Language (XUL) [36] is an XML-based user interface description language developed by Mozilla to build cross platform applications. WS-BPEL Extension for People (BPEL4People) [37] is based on the Web Services Business Process Execution Language (WS-BPEL), which is primarily designed to support business process behavior based on Web Services. BPEL4People is an extension that supports user interactions that enable a broad range of scenarios involving people within business processes. An example UML profile for a GUI layout is introduced in [38]. These modeling languages and concepts did not meet our needs of model implementation independent user interaction and support of a submit/response-style interaction paradigm. They are primarily aimed at describing and designing user interfaces. BPEL4People can be used to model both; however, BPEL4People treats end-users as other services. Developers have to develop matching user interfaces in traditional programming languages and, in addition, only basic operations for the interaction of client applications with human tasks are considered. In [39], the difference between workflow states and dialog states has been explained. That study suggested that strict separation between workflow states and dialog states should be overcome in future business process approaches, which also encouraged us to develop the seamless modeling framework for processes and dialogs. In [40], a concrete workflow language that can be exploited as an automated specification in workflow definition tools, as well as the basis for integrated business process and dialog modeling, was proposed. Our approach details the modeling aspects proposed for integrated business process and dialog specification in [40]. In [41], the relevance of several business process disciplines for today’s enterprises was explained and the gap between business process modeling, workflow definition


ModelFramework

27

and enterprise application development was characterized. Therefore, [41] sets the stage for the solution proposed in this article. The current article goes beyond [41] because [41] only identifies and describes the general conditions of process decomposition, whereas the current article proposes a concrete framework that is ready to use in concrete projects. Current issues and future challenges in process modeling have been evaluated in [42]. In this study, three separate groups of participants (academics, practitioners, and tool vendors) were interviewed in three rounds. The results were documented in two top 10 lists, one with current issues and the other with future challenges. The most important current issue in the first list is standardization, followed by the value of process modeling and model-driven process execution. With our work we address the issues of Business-IT-divide (issues related to the use of process modeling in IT versus business scenarios, rank 9) and process orientation (issues related to the development or education of a process-aware perspective in relevant stakeholders or organizational units, rank 10). Both of these aspects were rated highly by the tool vendors. The most important future challenge in the second list is the value of process modeling, followed by model-driven process execution and standardization. With our work we aim to address the challenges of Business-IT-alignment (the use of process modeling to support alignment between business and IT stakeholders, rank 4), ease of use (the ease of using process modeling methodologies, tools or notations, rank 9) and collaborative modeling (the involvement of multiple people in the modeling of processes, rank 10). Indulska et al. further identified five relevant research areas. We also address the expectations management area, in which the expectations and preconceptions of different stakeholder groups are examined. 7. Conclusion In this work we presented a common modeling method for continuous support of business and technical aspects in process-oriented enterprise application documentation. At the beginning, we described current problems in documentation that emerged in two of our industrial projects. These problems were primarily caused by the variety of different stakeholders and respective overlaps in the documentation, as well as notational and tool heterogeneity. We then introduced formcharts, and the scientific background of the proposed Process Model, Dialog Model, Technical Model and Data Model. The four models are described in detail and additional guidelines (e.g., for appropriate decomposition mechanisms and the use of formcharts) define how the models should be used. We also presented several levels of abstraction for the models and integration concepts for seamless documentation. Subsequently, we illustrated the chosen modeling language UML and notation BPMN with extensions for formcharts. The framework was applied within a comprehensive case study to demonstrate the use of the four models and the integration concepts. Lastly, we studied related work, focusing on modeling languages, enterprise architecture frameworks, tool implementations and research strategies.


ModelFramework

28

Acknowledgement The project Vertical Model Integration is supported within the program “Regionale ¨ 2007-2013” by the European Fund for Regional DevelopWettbewerbsfähigkeit OO ment as well as the State of Upper Austria.

References [1] M. Dumas, W. van der Aalst, and A. ter Hofstede, Process-Aware Information Systems: Bridging People and Software Through Process Technology. John Wiley & Sons, 2005. [2] D. Draheim, “Smart Business Process Management,” 2011 BPM and Workflow Handbook – Work, Planning and Collaboration Under the Impact of Social Technology, Digital Edition, pp. 207–223, February 2012. [3] D. Draheim and G. Weber, Form-Oriented Analysis – A New Methodology to Model Form-Based Applications. Springer, 2005. [4] A.-W. Scheer, ARIS – Business Process Modeling. Springer, 2000. [5] F. Pontico, C. Farenc, and M. Winckler, “Model-Based Support for Specifying eService eGovernment Applications,” in 6th International Workshop on TAsk MOdels and DIAgrams (TAMODIA’2007), 2007. [6] H. Seidlmeier, Process Modeling with ARIS. Vieweg+Teubner, 2004. [7] O. M. Group, “Business Process Modeling Notation Specification – OMG Final Adopted Specification,” Object Management Group, Tech. Rep. dtc/06-02-01, 2006. [8] M. Fowler, UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley, 2003. [9] D. Auer, D. Draheim, and V. Geist, “Extending BPMN with Submit/Response-style User Interaction Modeling,” in 1st International Workshop on BPMN (BPMN2009), July 2009. [10] C. Boehm and G. Jacopini, “Computational Linguistics – Flow Diagrams, Turing Machines And Languages With Only Two Formation Rules,” Communications of the ACM, vol. 9, no. 5, pp. 366–371, May 1966. [11] D. T. Ross, “Structured Analysis (SA): A Language for Communicating Ideas,” IEEE Transactions on Software Engineering, vol. SE-3, no. 1, pp. 16–34, 1977. [12] Object Management Group, “Business Process Definition MetaModel (BPDM) Beta 1,” OMG Document No. dtc/07-07-01, 2007. [13] J. A. Zachman, “A Framework for Information Systems Architecture,” IBM Systems Journal, vol. 26, no. 3, 1987. [14] S. Baina, H. Panetto, and G. Morel, “Towards a Product Oriented Process Modelling for Enterprise Applications Synchronisation and Interoperability,” in Enterprise Interoperability. Springer, 2007. [15] J. deJong, “Mega Modeling Maps Grand Plan,” SD Times on the Web, 2007. [16] D. Auer, V. Geist, W. Erhart, and C. Gunz, “An Integrated Framework for Modeling Process-Oriented Enterprise Applications and its Application to a Logistics Server System,” in 2nd International Symposium on Logistics and Industrial Informatics (LINDI2009), September 2009. [17] C. Natschl¨ ager, C. Illibauer, V. Geist, and D. Auer, “Identifying issues in modeling and model integration - a case study,” Software Competence Center Hagenberg GmbH, Tech. Rep. SCCH-TR-0948, June 2010. [18] E. Babbie, The Practice of Social Research, 8th edition. International Thomson Publishing Services, August 1997.


ModelFramework

29

[19] B. Boehm, H. Rombach, and M. Zelkowitz, Foundations of Empirical Software Engineering: The Legacy of Victor R. Basili. International Thomson Publishing Services, 2005. [20] H. Traetteberg, “UI Design without a Task Modeling Language - Using BPMN and Diamodl for Task Modeling and Dialog Design,” in Proceedings of the 2nd Conference on Human-Centered Software Engineering (HCSE 2008) and 7th International Workshop on Task Models and Diagrams (TAMODIA 2008), 2008. [21] P. Molina and H. Traetteberg, “Analysis and Design of Model Based User Interfaces - An Approach to Refining Specifications towards Implementation,” in Proceedings of the 5th International Conference on Computer-Aided Design of User Interfaces (CADUI 2004), 2004. [22] G. Sahu, Y. Dwivedi, and V. Weerakkody, E-Government Development and Diffusion. Idea Group Publishing, 2009. [23] V. Anaya, G. Berio, M. Harzallah, P. Heymans, R. Matulevicius, A. Opdahl, H. Panetto, and M. J. Verdecho, “The Unified Enterprise Modelling Language Overview and Further Work,” in 17th IFAC World Congress, 2008. [24] A.-W. Scheer, ARIS – Business Process Frameworks. Springer, 1999. [25] R. Harrison, TOGAF Version 8.1.1 Enterprise Edition: Study Guide. Van Haren Publishing, 2007. [26] D. Minoli, Enterprise Architecture A to Z: Frameworks, Business Process Modeling, Soa, and Infrastructure Technology. Auerbach Publishers Inc., 2008. [27] C. Atkinson, Component-based Product-Line Engineering with UML. AddisonWesley, 2002. [28] C. Atkinson and D. Stoll, “Orthographic Modelling Environment,” in Proceedings of FASE’08 – Fundamental Approaches to Software Engineering, Lecture Notes in Computer Science 4961. Springer, 2008. [29] C. Atkinson, D. Brenner, P. Bostan, G. Falcone, M. Gutheil, O. H. M. Juhasz, and D. Stoll, “Modeling Components and Component-Based Systems in KobrA,” in (A. Rausch, R. Reussner, R. Mirandola, F. Plasil, Eds.): The Common Component Modeling Example – Comparing Software Component Models, Lecture Notes in Computer Science 5153. Springer, 2008. [30] O. Weiss, Integrated System Modelling Using the Form-Oriented Analysis. Vdm Verlag Dr. Mueller, 2008. [31] K.-D. Schewe and B. Schewe, “Integrating Database And Dialogue Design,” Knowledge and Information Systems, vol. 2, no. 1, January 2000. [32] B. Schewe and K.-D. Schewe, “A User-Centered Method for the Development of DataIntensive Dialogue Systems: an Object-Oriented Approach,” in Proceedings of the IFIP International Working Conference on Information System Concepts: Towards A Consolidation of Views. Chapman & Hall, 1995. [33] K.-D. Schewe and B. Schewe, “View-centered Conceptual Modelling – an Objectoriented Approach. ,” in ER’96 – the 15th International Conference on Conceptual Modeling. Springer, 1996, pp. 357–371. [34] A. Seffah, J. Vanderdonckt, and M. Desmarais, Human-Centered Software Engineering. Springer, 2009. [35] P. P. da Silva and N. Paton, “UMLi: The Unified Modeling Language for Interactive Applications,” in UML 2000 - The Unified Modeling Language. Springer, 2000, pp. 117–132. [36] J. Filipe, J. Cordeiro, and V. Pedrosa, Web Information Systems and Technologies. Springer, 2007. [37] M. Kloppmann, D. Koenig, F. Leymann, G. Pfau, A. Rickayzen, C. Riegen,


ModelFramework

30

[38] [39]

[40]

[41] [42]

P. Schmidt, and I. Trickovic, “WS-BPEL Extension for People – BPEL4People,” IBM, SAP, 2005. K. Blankenhorn and M. Jeckle, “A UML Profile for GUI Layout,” in Object-Oriented and Internet-Based Technologies. Springer, 2004, pp. 110–121. D. Draheim, “Towards Seamless Business Process and Dialogue Specification,” in Plenary Talk in Proc. of 19th International Conference on Software Engineering & Knowledge Engineering (SEKE2007), July 2007. C. Atkinson, D. Draheim, and V. Geist, “Typed Business Process Specification,” in Proceeedings of EDOC’2010 – the 14th IEEE International Enterprise Computing Conference. IEEE Press, October 2010. D. Draheim, Business Process Technology - A Unified View on Business Processes, Workflows and Enterprise Applications. Springer, 2010. M. Indulska, J. Recker, M. Rosemann, and P. Green, “Business Process Modeling: Current Issues and Future Challenges,” in 21st International Conference on Advanced Information Systems Engineering (CAiSE 2009), 2009.