ISSN: 1204-5357

Reach Us +44-175-271-2024
All submissions of the EM system will be redirected to Online Manuscript Submission System. Authors are requested to submit articles directly to Online Manuscript Submission System of respective journal.

Applying Business Process Modeling Techniques: Case Study

Bartosz Marcinkowski1
  1. Researcher, Department of Business Informatics, University of Gdansk, Poland Postal Address: Piaskowa 9, Sopot 81-864, Poland, Organizational Website: www.kie.wzr.pl, Email: Bartosz.Marcinkowski @ univ.gda.pl
 
Copyright: ? Bartosz Marcinkowski, 2010
 

Visit for more related articles at Journal of Internet Banking and Commerce

Abstract

Selection and proper application of business process modeling methods and techniques have a significant impact on organizational improvement capabilities as well as proper understanding of functionality of information systems that shall support activity of the organization. A number of business process modeling notations were implemented in practice in recent decades. Most significant of the notations include ARIS, Business Process Modeling Notation (OMG BPMN) and several Unified Modeling Language (OMG UML) extensions. In this paper, the assessment whether one of the most flexible and strictly standardized contempo-rary business process modeling notations, i.e. Rational UML Profile for Business Modeling, enable business analysts to prepare business models that are all-embracing and understandable by all the stakeholders. After the introduction, me-thodology of research is discussed. The following section presents selected case study results. The paper is concluded with a summary.

Keywords
Business Process Modeling; UML; Rational UML Profile for Business Modeling; Business Goal; Business Use Case Diagram; Stereotype; Business Use Case Specification, Business Object Model

1. Introduction
Modern enterprises and organizations continuously seek new domains of improvement of both their business activity and development process of software that supports the organization. It is business process modeling (Williams, 1967) that is one of key concepts of organization improvement approaches. Business process modeling allows the analyst to capture the broad outline and procedures that govern what it is a business does and thereby provides an overview of where the proposed software system being considered will fit into the organizational structure and daily activities (Sparx, 2000). In fact, any significant transaction based system development should seriously consider mentioned discipline as the starting point – many failures in IT projects can be traced back to a mismatch between the physical process and the IT process (Turbit, 2005). Numerous business process modeling methodologies and techniques were applied over the years; in recent years, market was dominated by ARIS tools and notation. Simultaneously, two techniques, developed by well-known standardizing organization, i.e. Object Management Group, gained on popularity and significance:
• Unified Modeling Language (OMG UML, 2009);
• Business Process Modeling Notation (OMG BPMN, 2009).
Unified Modeling Language is a de facto standard in Software Engineering. Features of the language are discussed in great detail in numerous books, just to mention (Booch, Rumbaugh and Jacobson, 2004), (Dennis, 2005), (Eriksson, Penker, Lyons and Fado, 2004) as well as (Wrycza, Marcinkowski and Wyrzykowski, 2005). Thanks to custom extensions, including Eriksson-Penker Business Extensions (Eriksson and Penker, 2000) as well as Rational UML Profile for Business Modeling (Johnston, 2004), UML is not only a useful business process modeling tool, but most robust and flexible notation available; the notation that can support complexity management, reducing building time as well as increasing the quality of target product (Baker, 2001). Although designed primarily to meet information systems modeling needs, the UML has potential advantages over BPMN. First of all, BPMN is not intended to support organizational structure modeling and lacks features covering relationships among documents used within organization. Secondly, applying UML in business modeling stage enables seamless notational transition to information system modeling stage. Finally, UML is in fact a set of techniques and notations. Business analyst, based on his/her experience, is free to select the diagrams that shall solve a stated problem in most efficient and readable way and exclude potentially not user-friendly UML diagrams. Extended comparison of UML and BMPN features is included in (Marcinkowski, 2008). Current paper verifies usefulness of Rational UML Profile for Business Modeling by providing selected components of a case study that was carried out in a property developer company.

2. Methodology
In order to verify whether well-defined Rational UML Profile for Business Modeling provides a good balance between usability (and thereby may be commonly accepted by business users) and precision, a series of case studies was carried out in property developer companies. Necessity of taking into account a number of changes in internal procedures of the companies that compete on a dynamic real estate market enables assessing the flexibility of business modeling notation used. Within individual case studies a detailed analysis of documents processed by different departments of companies is conducted as well as direct interviews with employees and managers are carried out. Individual interviews were conducted on different company management levels (see Table 1).
Interview protocols are prepared in structured textual form, supplemented with initial drawings of UML diagrams. All relevant procedures are recorded and documented. After completing initial version of a case study, the study becomes a subject of two-stage evaluation process. Employees and managers involved in original interviews verify prepared diagrams, bring up remarks and provide qualitative evaluation of userfriendliness and usefulness of diagrams presented. After adjustment, final acceptance is carried out.
A business model created using Rational UML Profile for Business Modeling may be substantially diverse. Business diagrams are technically equivalents of system diagrams so it is possible to use most diagrams included in UML 2.x specification for business modeling purposes. Practical analytical purposes as well as “technical” nature of some UML diagrams seem to make those diagrams not an optimal business modeling-related solution. It should be bore in mind that there are people not familiar with IT that take part in business modeling process, so threat of misunderstanding a model that is intensely complicated or based on less common diagrams emerges. Thus, the relevance and popularity of such diagrams as business activity diagrams, which are along with business use case diagrams and business class diagrams the fundamental artifacts of most business models created using UML.
Business models most often consist of two main parts: business use case model and business object model (Heumann, 2003), as presented on Figure 1. Models prepared within case studies conducted included business goals of individual companies as well.
Due to the large scale of case studies results, business object model is only briefly discussed in the current paper.

3. Selected case study results

3.1. Property developer company business goals
Within preliminary interview with member of the company board, main goals of the company SP-1, measures of the goals as well as scope of the company activity were described. As presented in Figure 2, leading goal of the company is balanced development. In order to achieve that, the company is building its assets, sustains low credit risk, acquires new clients within market niche and optimizes investment process. The company is not planning to enter new domains of activity. Each of the top-level business goals may be divided into subsequent sub-goals, as presented in the figure.
Business goals, modeled as stereotyped UML classes linked with dependency relationships, proved to be a commonly accepted modeling technique. No diagram misinterpretations were recorded when the diagram was evaluated. Interviewees’ confusion in early diagram development stages was related to direction of UML dependencies. Attempts to include secondary business goals in the diagram rendered it unreadable, hence business goals model ought to be decomposed in such case.

3.2. Business use case diagrams
Research conducted allowed to identify individual business use cases defining company activity, business actors and business workers that interact with the business use cases. Due to complexity of property developer company business use case model, the model was decomposed. Individual business use cases, presented in Figure 3, became a subject of further refinement. As a result, apart from top-level business use case diagram, a series of detailed diagrams were prepared.
Business use case diagram was still described as user friendly. Having said that, some misinterpretations were detected. Interviewees had no difficulties in distinguishing business actors and business workers, but supplementary business actors/workers hierarchies had to be developed in order to ensure understanding of the whole picture. Notion of abstract modeling category required additional clarification. Primary issues were related to interpretation of include and extend relationships. Since including additional details such as association multiplicities and notes raised additional questions and doubts, the features were removed from all the business use case diagrams.
One of detailed business use case diagrams mentioned earlier in the paper is presented in Figure 4. The diagram refines “Prepare investment” use case, originating from the toplevel diagram.

3.3. Specification of business use cases
Business use case model usually includes textual, tabular of diagrammed (provided that diagrams do not exceed conceptual level) specifications of individual business use cases. While conducting case studies tabular form was consequently used as a natural compromise between informal textual description and formality of UML diagrams. Exemplary business use case specification, related to the “Perform pre-investment site reconnaissance” use case, is presented in Figure 5. As technique applied is not defined in Rational UML Profile for Business Modeling, verification issues are not discussed.

3.4. Business object model
Final form of a complete SP-1 case study introduced four distinct UML diagrams, enriched with a set of stereotypes defined in Rational UML Profile for Business Modeling. The diagrams included:
• business activity diagrams and business sequence diagrams for modeling behavior;
• business package diagrams and business class diagrams form modeling logic. Without any doubt, it is the business activity diagram that was found the most suitable form of business use case specification. Figure 6 presents business activity diagram specifying “Tax-related due diligence” business use case.
Business activity diagrams proved to be both understandable and having adequate modeling capabilities. In fact, in order to preserve user friendliness, modeling categories introduced in UML 2.0 were not implemented. In selected application areas, such as modeling intensive documents exchange, business sequence diagrams were described by interviewees as more efficient. Having said that, most property development company employees handled nested combined fragments as well as time constrains poorly, hence these modeling categories ought to be used with caution.
Attempts were made to verify usefulness of remaining UML 2.x diagrams in business modeling. In all the cases however initial diagrams were turned down by interviewees as more complicated / not introducing relevant new functionality to the business model elaborated.

4. Summary
While a nearly sole role of Unified Modeling Language in information systems development is rarely questioned, development of business process modeling-related techniques led to creating formidable competition for UML-based extension. Having said that, most important UML strengths in the business modeling domain include:
• all-embracing modeling capabilities, taking into account not only behavioral features of the company, but logical ones and optional business goals as well;
• reliable tool support;
• standardization and common familiarity with the notation, especially among information system analysts and designers
Particular UML extension applied while conducting case studies, i.e. Rational UML Profile for Business Modeling, is a natural choice when information development is executed in accordance with Rational Unified Process, one of the leading IS development methodologies. Selected diagrams of the notation proved to be understandable by non-IT personnel. Greatest challenges were related to relationships between individual modeling categories (dependencies between use cases in particular) as well as detailed business use case specification. It was business sequence diagrams that were the most often misinterpreted diagrams among finally accepted ones. Most UML 2.x diagrams proved to be too technical for business modeling needs. Attempts to offer timing diagrams for selected procedures as well as communication diagrams for processes that involve intensive document flow have not produced satisfying results. Thereby business modeling needs can effectively be met using only a subset of UML 2.x language enriched with stereotypes defined in Rational UML Profile for Business Modeling. Such subset is often referred as UML Light version. In particular, business analyst may:
• use stereotyped class diagrams to effectively capture business;
• supplement business use cases with semi-formal, tabular specifications, creating business use case model; a lot of effort ought to be invested in clarifying relationships between use cases in order to avoid future misinterpretations;
• formally specify individual business use cases using simplified (UML 1.x style) and stereotyped activity diagrams to capture business behavior; in some cases (intensive document exchange in particular) business sequence diagram proves useful; it is vital to avoid manifold nested UML combined fragments;
• express organizational structure as a part of business logic with stereotyped packages; as stereotyping dependencies between packages introduces confusion, the redundant stereotypes should be avoided.

Acknowledgements
Supporting agency: Polish Ministry of Science and Higher Education

Tables at a glance
Table icon
Table 1
 

Figures at a glance
Figure 1 Figure 2 Figure 3
Figure 1 Figure 2 Figure 3
 
Figure 1 Figure 2 Figure 3
Figure 4 Figure 5 Figure 6
 

References
























Journal of Internet Banking and Commerce

Copyright © 2024 Research and Reviews, All Rights Reserved

www.jffactory.net