SAMI 2013 • IEEE 11th International Symposium on Applied Machine Intelligence and Informatics • January 31 - February 2, 2013 • Herl’any, Slovakia
Business Process based Initial Modeling at Software Development J. Tick Óbuda University/ John von Neumann Faculty of Informatics/ Software Engineering Department, Budapest, Hungary
[email protected] Abstract—The fundamental problem of high-level quality software development is the elaboration of well-designed and correct model of the developing system. The most critical phase is the “birth” of the model, the specification of the initial model. This paper describes the method to use the already existing Business Process Model to set up the initial model for the software to be developed. Especially Business Process Management systems can be well described by business processes using workflow. This paper makes recommendations how to incorporate workflow in the development process. The basic principle of the method to elaborate the initial model is that using the usually already existing workflow an UML action diagram can be worked out with the help of mapping that can be a useful additional source for further development processes.
Figure 1. Workflow using WfMC’s notation
based modeling process, its steps and methodology has gone through a great evolution in the last fifteen years. The today most spreading and successful approach has to be mentioned by all means, which is the Model Driven Architecture (MDA) elaborated by the Object Management Group (OMG). The MDA development focuses more on the functionalities and the behavior of the system, it does not highlight the business process itself. [3] Development experience shows that regardless of the traditional approach used for the development, communication misunderstandings occur and to various extent though, errors are built in the model using any of the approach. The common goal of both parties (costumer and developer) is to reduce the number of such errors in order to improve the quality and correctness of the initial model. This paper looks into the case of such information systems that can be well described by business processes and gives a methodology to achieve a more stable initial modeling and as such a better quality software development. A significant part of software development strives to give solutions to problems featured by business processes. The operational models of these systems are well formulated with the descriptive notation system of some Business Process Management. In our case it is examined how these business processes drawn up by workflow can be utilized in the course of software development.
I. INTRODUCTION The increase of software system sizes has triggered a drastic growth of complexity. The relationship is at least quadratic between the size and the complexity. [1] The basic problem of the development of such complex software systems is the definition of the correct model of the system to be developed. The consequence of an erroneous model is that the developed software product does not fully meet the customer’s requirements. Practical experience is that the costs of posterior improvement depend to a great extent on the phase in which the error was made. The error made in the early phases of the development, that is at the construction of the model is the most cost-intensive. [2] That is why a critical point in software development is the elaboration of a well-designed and correct model from the aspect of cost-effectiveness as well as of customer satisfaction. Naturally, in the process of development the worked out model can be modified partly due to some changes in the requirements of the customer and partly due to some professional considerations (e.g. a change in database management considerations, reorganization of network communication, avoidance of bottle neck problems). Regarding the model life cycle, the most critical phase is the “birth” of the model, the specification of the initial model. In this phase the customer cooperates (communicates) intensively with the software developer, while a source of the problems can be a communication gap. For the elaboration of models that is the design of the initial models several methods and approaches exist. The former dataflow-based modeling, which belonged more to the structured development methodologies and in principle described the information flow and process in the system was replaced by the ones offered by UML and was linked to object-oriented development [4] The UML-
978-1-4673-5929-0/13/$31.00 ©2013 IEEE
II.
WORKFLOW AS THE INITIAL MODEL
When developing software products based on business processes the costumer determines the business processes and formulates them by certain notation system. In the field of Business Process Management (BPM) several solutions are known, however, the most authentic one is the Workflow Management Coalition (WfMC), the workflow recommended by the most acknowledged professional association of experts working with BMP.
141
J. Tick • Business Process-based Initial Modeling at Software Development
AND-Join and OR-Join basic components. [6] In natural way the costumer can draw up and store his/her workflows using any type of notation systems, although the notation system of WfMC is the most widespread. Taking off the fact that in the case of BPMtype software systems business processes are available, furthermore, it can be easily designed in this form using the professional skills of the contracting party, these workflows can be regarded as the initial models. The question is then arises, how the information given in these workflows can be implemented in the software development process in such a way that it becomes a consistent element of the UML chart system. Hereinafter it will be examined how the information in the workflow can be transferred to the UML model.
According to the WfMC definition the workflow is „the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules” [5]. In this sense the following must be defined separately in case of workflows: A. Activity An activity is the basic component of a workflow that means a logical work-step in the process. From the aspect of our examination, in the course of modeling the complexity of an activity depends on the abstraction level, and as such with stepwise refinement and with the decomposition of the abstraction level an activity gets simpler even up to the basic operations. In the WfMC’s notation an activity is given as a simple rectangle.
III.
THE MAPPING OF THE WORKFLOW TO THE UML ACTIVITY DIAGRAM The workflow taken as the starting model must be integrated into the UML diagram system used in the development. However, it must be transformed into a UML type diagram. Regarding the basic components and the convention system of the workflow out of the UML diagrams the activity diagram has the most in common with the workflow. Thus the mapping can be conducted quite easily. A basic principle in the course of mapping is that the mapping mechanisms, that is the correspondence of the two sides must be simple, since this action can generate most of the errors. Furthermore, revealing the errors in the case of mapping is not without effort. The regular mapping mechanism is the 1:1 mapping. We try to
B. Process A process is the network of the activities that at the same time defines the interrelations of the activities. The process in its entirety represents the business procedure to be processed or some of its sub-processes. This representation decides on the beginning, ending of the process, gives information about the activities and about other features of the process.. C. Case A case defines a certain schedule of the process execution. During each case controlling might differ, which is described by a control pattern. The control pattern is a component of the control-flow. The WfMC defines sequential, parallel, selective and iterative patterns, which are realized by AND-Split, OR-Split,
Figure 3. Workflow mapped from WfMC’s notation to UML activity diagram
Figure 2. Equivalents for mapping from WfMC’s notation to UML activity diagram
142
SAMI 2013 • IEEE 11th International Symposium on Applied Machine Intelligence and Informatics • January 31 - February 2, 2013 • Herl’any, Slovakia
The input of the recommended methodology to build this model consists of three documents: the original workflow, the user scenarios and the scope. The detailed design can start from the Initial Model built as the output. The steps, their order and relations to each other in the methodology are given in Figure 4. Starting from the Workflow, the first step is mapping, which is a 1:1 method as said before. Refinement as the next step happens already in the activity diagram, which is invoked to create the consistency of the model, and to reveal the not yet cleared details. The diagram drawn up in this way must be clear and well interpretable for the information technologist. On the other branch the user scenario is the starting point, which means the definition of the usage, the operational behavior of the system. The costumer or its professional advisor takes a big role in its elaboration. We have to strive to give a complete description i.e. to include each significant element of system operation. The detailed elaboration and the depth of the description are significant features, we will see it later. Based on the Scenario a Use Case model can be drawn up which includes the system actors (users) and the basic use cases. As the next step this Use Case model is refined, supplemented and made more precise. The components “include” and “extend” are defined here. The starting point here is the regular operation (regular business flow). After its presence the special cases are to be managed. Here the “extends” that realize exceptions and that help to extend the model with behaviors different from the regular have a significant role (for example: the customer backs from buying, invalid PIN number, etc.). Not even the detailed and thoroughly elaborated Use Case model can include the necessary details for implementation; it can rather be used as an overview diagram. It gives the arrangement of the use cases handled by the system. The sequence diagram and/or the state chart [3] is usually used for system refinement and for executable activities in the use cases. In our case the workflow mapped to an activity diagram that was introduced on the other branch of the approach becomes important. This workflow has already contained executable activities during a given use case. In the third branch the initial object model is formulated. We start from the scope, which is the brief description of the system and gives information about the system (system components, structure, features etc.) The selection, the categorization and the filtering of nouns would help to define the possible objects. The linguistics structures will describe the interrelations of the objects. In such an early stage of development the Object-class Stereotype can be excellently used (boundary, control, entity). As a second step in the course of setting up the object model a static model is worked out, but beyond the scope to build a precise model those pieces of information that rather describe the dynamic behavior and were defined in the user scenarios must also be considered. This is especially practical since the formulation of the interactions also includes the participating entities as well, which would appear as objects in the model. The initial model built from these three parts would serve as the input of the detailed design.
follow this mapping mechanism. Figure 2. well describes the logical mapping of the component. Certainly, there are discrepancies in the two notation systems regarding an interpretation, which is especially true for the activity basic component, but it does not influence the quality of the drawn up model. As shown in the figure with the help of the components of the activity diagram the sequential, the parallel, the alternative and the cyclical execution of the workflow model can also be realized. Similarly, the essential synchronization of the parallel activities can also be conducted. The alternative execution is reduced to a condition thus in case of the activity diagram it can be formulated together with a logical function. For instance, which activity has the necessary resource: E
