A Role-Based Framework for Business Process Modeling Artur Caetano1,2, Marielba Zacarias2, António Rito Silva1, José Tribolet1,2 1 Department of Information Systems and Computer Science, Instituto Superior Técnico, Technical University of Lisbon. 2 Center for Organizational Engineering), INOV, INESC Inovação. Primary contact e-mail: artur.caetano@inov.pt Abstract Business objects are object-oriented representations of the concepts of interest in an organization, such as activities, resources and actors. Business objects collaborate with one another in order to achieve business goals, showing different behavior and properties according to each specific collaboration context. This means the same business object may be perceived differently depending on the business objects it is collaborating with. However, most approaches to business process modeling do not separate the collaborative aspects of a business object from its internal aspects. To cope with such issues, this paper makes use of role modeling to separate these concerns while increasing the understandability and reusability of business process models. This approach makes use of object-oriented concepts to separate a business process model into a business object model and a role model. The business object models deals with specifying the structure and intrinsic behavior of business objects, while the role model specifies its collaborative aspects. 1. Introduction Business process modeling specializes on describing how activities interact and relate with other organizational elements while supporting the operation of the business. The representation of an organization and its processes has been the focus of research in past years and significant work has been done on developing business process modeling concepts, methodologies and ontologies as well as on the specification of process modeling languages [11, 18, 19, 21]. Business process modeling can also be used for multiple purposes, such as facilitating human understanding and communication [33], supporting process improvement and re-engineering through business process analysis and simulation [9, 19], automating the execution of business processes [2,25] and facilitating coordinated business and system development by keeping the alignment between processes and their support systems [6]. Modeling business processes involves capturing the structure of its business objects and their relationships. A business object represents a concept of interest in the organization, such as activities or human or automated actors. Identifying business objects is fundamental to help understanding and evolving the business by facilitating its communication and analysis and promoting business object reuse. However, properly identifying business objects is not straightforward. One of the reasons for this is that business objects are used in different business contexts. On the one hand, a business object relates to a set of other business objects, leading to a highly connected relationship representation that is frequently not easy to analyze. On the other hand, a business object exhibits different behavior according to the relationships it has at a given time. This results from an object potentially playing different roles in different collaborations. Partitioning the universe of process modeling into different areas of concern, each of which can then be handled independently, is fundamental to represent an organization’s business objects. This paper proposes using two complementary models, the role model and the business object model. The role model describe business object collaborations and the extrinsic features of business objects. The business object model describes its structure and the properties of a business object that do not depend on a specific context. The relationships between business objects are specified by a set of roles the objects play in a collaboration. These concepts are modeled using object-oriented constructs and are represented with the Unified Modeling Language (UML). 2. Business Process Modeling The Workflow Reference Model [34] defines a business process as a set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships. This definition extends the definition proposed by Davenport and Short [8], stating that a business process is a set of logically related tasks performed to achieve a defined business outcome. Most approaches to business process modeling focus on some sort of process diagram, which show how activities are coordinated in the course of a business process. Indeed, there is little disagreement about the key elements of a process diagram: it must contain activities and activity connectors. In addition, there are usually ways to represent decision points, and ways to express various activity coordination patterns, such as sequential flow, branching and parallel execution. Swim lanes are often introduced to suggest which departments or individuals are responsible for which activities, therefore representing the roles of these actors. Two fundamental proposals that make use of these concepts are Role Interaction Networks [27] and Role Activity Diagrams [24]. Here, roles are considered as sets of ordered interactions. Activities describe the interaction between pairs of actor roles, from a driving to a target role. The Object Management Group has summarized the basics of process diagrams in its upcoming UML 2.0 activity diagram notation [22]. Similarly, the BPMI working group has just completed BPMN, a notation that is especially designed for describing business processes in business process diagrams [5]. However, at a high-level of abstraction UML 2.0 activity diagrams and BPMN are quite similar. In addition to these notations there are others like the IDEF notation family and the proprietary notations supported by process and workflow modeling products. However, business process modeling is not limited to process diagrams. The focus of this paper is not on process diagrams but on the description of the roles that are used to specify the responsibilities of business objects. A business object is the model of a concept in the business universe of discourse. It plays roles in a business process by means of participating in different activities. Business objects participate in different business processes in different contexts, thus playing multiple roles. It is important to note that process diagrams do not fully describe the business object structure and relationships, and do not emphasize how goals are achieved by performing an activity. Besides, they only identify actor roles, i.e. the roles of the performer of an activity. This means, for example, that the properties of a resource that is used by multiple activities are not separated according to its usage context. The next section introduces the fundamental concepts behind role modeling. 3. Role Modeling Role theory started to generated interest among social scientists from many backgrounds, such as psychology and sociology, in the late 1920s. Its central concern has been with patterns of human conduct and with context and social structure as well as with individual response. The motivation for roles is to allow particular viewpoints regarding the factors presumed to be influential in governing behavior and lies on a theatrical analogy of actors playing parts or roles in a play, as Biddle and Thomas [6] have stated: “When actors portray a character in a play, their performance is determined by the script, the director’s instructions, the performances of fellow actors, and reactions of the audience as well as by the acting talents of the players. Apart from differences between actors in the interpretation of their parts, the performance of each actor is programmed by all of these external factors; consequently, there are significant similarities in the performances of actors taking the same part, no matter who the actors are.” There exist multiple definitions for the concept of role. For example, in the late 1970s, sociological role theorists defined a role as “a comprehensive pattern for behavior and attitude” [30] or as “behavioral repertoire characteristic of a person or a position” [3]. However, there is still no consensus on the definition or properties of role. Nonetheless, the concept of role is used in computer science and software engineering as a modeling technique that supports the separation of concerns, i.e. the separation of the “behavioral repertoire characteristics” of some concept. It is being used in methodologies such as RM-ODP [15] and in several object-oriented frameworks [11, 13, 15, 27]. Kristiansen [17] has proposed a set role properties, which are commonly regarded as a conceptual basis for defining roles. In business process modeling there are also approaches based on role modeling. Despite being quite similar, we emphasize Role Interaction Networks [27] and Role Activity Diagrams [24]. Here, roles are considered as sets of ordered interactions. Activities describe the interaction between pairs of actor roles, from a driving to a target role. However, these approaches do not fully depict context, describe object relationships or separate other concerns than actor roles. 3.1 Business Objects and Roles Modeling consists of identifying things of interest in a given universe of discourse and representing them in a model. In business modeling, the universe of discourse corresponds to what is perceived of an organization as being reality by business domain experts. Ontologies typically distinguish entities (nouns) from activities (verbs) in the universe of discourse. Entities are things that exist in the business, either concrete (e.g. a person) or abstract (e.g. an organization). Activities are things that happen in the business making use of entities. Both of these concepts are modeled as specialized business objects. A business object is then the super type of all objects that represent business concepts with a well-defined boundary and identity, and encapsulate properties such as its definition, attributes, behavior and relationships [23, 24]. The state of a business object is characterized by its attributes and values. The behavior are the actions a business object is capable of performing to fulfill its purpose, including changing its intrinsic attributes and collaborating with other business objects. Business objects have intrinsic features which describe it in isolation and extrinsic features which arise from the relationships with other business objects [17]. For example, a person has intrinsic features such as age and sex, and extrinsic features such as job position and salary which derive from the relationship between the person and an organization. Intrinsic features may change over time (e.g. age) but always characterize the object. However, extrinsic features may eventually become inappropriate or conflicting (e.g. salary of an unemployed person, salary of a person with multiple jobs). One way to separate the intrinsic features from the extrinsic features of an object is by the usage of roles [4, 17, 26]. Roles, as a modeling construct, aim at separating the concerns that arise from business object collaborations. We define a role as the observable behavioral of a business object defined in a specific collaboration context. Thus, a role represents the extrinsic features of a business object when it participates in some activity. 3.2 Identifying Roles To distinguish roles from “natural types” or entities, Guarino et al. proposed two criteria [12]. The criteria asserts that a role is founded and lacks semantic rigidity. Something is founded if it is defined in terms of relationships with other things in a given context. For instance, the concept of “reader” is founded since for a person to be a reader, there must be something being read. Conversely, the concept of “person” is not founded, since its intrinsic properties (e.g. age, sex) are defined in their own regardless of the collaborations with other things. Something is semantically rigid if its identity directly depends on being kind of some class. The concept of “book” is semantically rigid since it identity is still that of a book regardless someone is reading it or not. In contrast, “reader” is not semantically rigid, since an entity filling the role of reader still retains its identity outside the context of that role. For example, a person is a reader while reading a book, but when it stops reading it, it is still a person. So, roles are founded and semantically nonrigid types while entities are non-founded and semantically rigid types. 4. Role-Based Business Process Modeling Our approach to business process modeling deals with decomposing the modeling universe into two complementary models, the business object model and the role model, and binding these two models into an integrated specification of the business. The business object model deals with specifying the structure and intrinsic properties of business objects. At this level of abstraction, an organization is modeled as a network of business objects. However, business objects relate to other business objects in specific contexts and are often used in more than one context, where they may play different roles. So, the roles for a business object only need to be included in its definition when the object acts in the collaboration contexts described by the roles. It is also impossible to forecast the possible roles for a business object, and adding superfluous roles impairs several design quality attributes such as understandability, maintainability and reusability. To deal with such issues, roles and business objects should be dealt with separately, and later bound together. The concept of role allows a system to be decomposed into a set of business objects capable of clearly separating core parts and collaboration-dependent parts, and then to abstract and compose such objects. Consequently, a set of roles helps business objects to be defined to be more reusable and extensible, and also the roles become more reusable as a unit encapsulating specific collaborations. Roles are organized into role models, which deal with specifying the network of related roles required for a collaboration to happen. The business process model then consists of two complementary models, the business object model and the role model. These models are represented in the Unified Modeling Language [21]. The specific business domain concepts not addressed by the UML are defined using the UML extensibility package, which specifies how UML model elements can be extended and customized with new semantics by the use of stereotypes, tagged values and constraints. A coherent set of such extensions defined for a specific purpose makes up a UML profile [2, 21]. The next subsections describe business object models, role models and views. 4.1 The Business Object Model The business object specifies the structure and intrinsic properties of business objects. Business objects are coordinated towards the achievement of goals, being the coordination mechanism the business process. A business process is composed of activities that use resources, such as materials or information, to produce output resources, thus achieving business goals. The activities of a business process are performed by one or more actors or business support systems, which represent people, systems or a combination of both. At a large scale, business processes are composed as value chains that produce value to external customers [28]. Figure 1 and Table 1 describe the business object related stereotypes. A business object is a UML class. Therefore, business objects, such as activities and resources, may be aggregated, composed and generalized. Business object models are represented as UML class diagrams and the intrinsic behavior of the objects is represented using UML’s behavioral diagrams. However, all collaborations between business objects are not represented in this model but in the role model. Table 1. Business object stereotypes. Stereotype Parent Description Business – A concept of interest in the organization.. Object Business verbs describing how a piece of work Business Activity is performed. Activities are performed by Object actors, and operate over resources. Business nouns describing. Entities usually Business Entity participate in multiple business collaborations Object and outlive single interactions. Input or output of an activity representing Resource Entity things such as materials or information. Someone (human actor) or something (automated actor, such as an information system Actor Entity or a production machine) that can perform the actions required by an activity. A measurable state that the organization intends Goal Entity to achieve. Goals are achieved by performing activities. and behavior necessary to realize its participating collaborations. Roles are modeled as classes while role models correspond to UML packages. Roles can be constrained. A constraint asserts conditions between the roles in a role model and can be expressed informally or formally (e.g. in OCL). An example of a constraint is disallowing two roles to be played simultaneously by the same player, such as forbidding a person playing the role of Teacher and that of Student in the same context. Binding the role model with the business object model states the roles an object is able to play. Roles are a separation of concerns mechanism that allows business objects to be observed from different perspectives. For example, the attributes of the Book business object (an entity) are perceived differently by different activities. While Title has the same meaning, Cost represents the production cost to the Manufacture activity while it represents the book price to the Marketing activity. Attributes such as the book style do not make sense in the context of the Manufacture activity (v. Figure 3). Figure 1. Classes in the business object profile. A Sell Product activity can be composed of subactivities such as Identify Customers and Handle Order (v. Figure 2), which can be further decomposed into smaller activities. These activities may be reused in multiple business processes. On the other hand, each activity can be also specialized. For example, Sell Product can be specialized as Sell by Mail Order and Sell Online. In such a case, Handle Order also requires to be specialized to process incoming mail orders and online requests, respectively. Note that composition and specialization does not imply any collaboration constraints between the activities. Figure 2. Example of activity decomposition and specialization. 4.2 The Role Model The role model describes the network of roles required for a specific collaboration to happen. As a player of a collaboration, a role defines a set of extrinsic properties Figure 3. The Book business object as seen by two different activities. Figure 4 shows two base role models, Supply and Pay and a composed role model, Purchase. The top compartment of the package depicts the roles within the role model and the lines represent a collaboration relationship between the roles. The bottom compartment is an activity or interaction diagram describing the behavior of each role. Each role is a class and has methods and attributes concerning the specific collaboration context (e.g. the Supplier role in the Supply role model has the inquire and order methods). The Purchase role model describes the collaborations between a Client and a Supplier, while the Pay role model, specifies Payer and Payee. defining the collaboration between the Instruct activity and the Course Material resource through the Resource role. The Resource role is a common pattern between entities and activities, and provides its player the capacity of being created, accessed, modified, produced or consumed by some activity. «Entity» Course Material «Actor» Course Supervisor «Actor» Instructor Resource Client [Instruction] [Instruction] Supervisor Subject [Supervision] [Supervision] Performer Service Instruct [Instruction] [Instruction] [Instruction] Figure 4. Supply, Pay and Purchase role models. Purchase is composed of Supply and Pay. The Purchase role model is a composition of the Supply and Pay role models. A purchase results from supplying a product and paying for it. Figure 5 shows the binding of the roles within the Purchase role model to a set of business objects. In the first case, a Retailer acts as the Client and Payer to a Producer who is a Supplier and a Payee to the Retailer. However, the Retailer may also act as a Supplier (and a Payee) to a customer. Figure 5. Binding roles to business objects. 5. Example This example describes a simplified business process for instructing (Figure 6). The goal of this process is adding a skill (i.e. adding a new role) to a learner. The Instruct activity makes use of an Course Material entity and is performed by an Instructor. The overall instruction process is controlled by a Course Supervisor. As an input, the activity takes an “unskilled” actor, the Learner, and outputs the same actor with the new skill. Enhancing this model with roles makes the behavior of each business object clearer. «Activity» Instruct New Role «Actor» Learner forbid Creator [Instruction] Figure 7. Top-level process view with the roles played by each business object. It also shows the collaboration between an Course Supervisor and the Instruct activity, reusing the Supervision role model as defined in the previous example. The collaboration between the Instructor and the Instruct activity is modeled also reusing the Performer/Service role model. The interaction between the Instruct activity and the Learner actor results in a new skill, modeled as a role. This is represented as the result of the collaboration of the Instruct role on the Instruct activity with the Creator role on the Learner actor. The Creator role can be interpreted as a role constructor that enables new roles to be attached to its container business object. Finally, a forbid constraint is defined within the instruction role model, namely between the Performer and Creator roles. This constraint means the course instructor can not be simultaneously the learner in this process. 6. Summary This paper has presented the fundamental concepts towards an object-oriented framework for role-based business process modeling. It relies on specifying business objects and making the collaborations between these dependent on the usage context. This is accomplished by specifying and later reusing roles that are assigned to business objects and composed within role models. References Figure 6. Top-level business object model for course instruction. Figure 7 illustrates the role-based process model where a set of roles has been bound to the business objects, 1. W.Aalst, K.Hee, Workflow Management, MIT Press, 2002. 2. S.Alhir, Unified Modeling Language Extension Mechanisms, Distributed Computing, 1998. 3. C. Bachman, M. Daya. The role concept in data models, Proceedings of the 3 rd International Conference on VLDB, 1977. 4. B. Biddle, E. Thomas, Role Theory, Concepts and Research, Kluwer Publishers, 1979. 5. BPMI, Business Process Modeling Notation, Version 1.0, 2004 (from www.bpmn.org) 6. Y. Chan, Why Haven’t We Mastered Alignment?: The Importance of the Informal Organization Structure, MISQ Executive, Vol.1, No.2, 2002. 7. B. Curtis, M. Kelner, J. Over, Process Modeling, Communications of the ACM, Vol. 35, No. 9, 1992. 8. T. Davenport, J. Short, The New Industrial Engineering: Information Technology and Business Process Redesign. Sloan Management Review, 1990. 9. H. Eertink, W. Janssen, P. Luttighuis, W. Teeuw, C. Vissers, A Business Process Design Language, World Congress on Formal Methods, Springer, 1999, pp. 76-95. 10. H. Eriksson, M. Penker, Business Modeling with UML, OMG Press, 2001. 11. G. Gottlob, M. Schrefl, B. Röck, Extending Object-Oriented Systems with Roles, ACM Transactions on Information Systems, Vol, 14, 1996 pp. 268-296. 12. N. Guarino, M. Carrara, and P. Giaretta. An ontology of meta-level categories. Proceedings of the Fourth International Conference on Knowledge Representation and Reasoning, pages 270–280. Morgan Kaufmann, 1994. 13. T. Halpin, Augmenting UML with Fact-orientation, 34th Hawaii International Conference on System Sciences, IEEE Press, Hawaii, USA, 2001. 14. ISO, ISO/IEC 10746 ODP Reference Model, International Standards Organization, 1995. 15. E. Kendall, Agent Roles and Role Models, New Abstractions for Multiagent System Analysis and Design, International Workshop on Intelligent Agents, 1998. 16. B. Kristiansen, Object-Oriented Modeling with Roles, 1 st International Conference on Object Information Systems, 1996. 17. F. Leymann, D. Roller, M. Schmidt, Web Services and Business Process Management, IBM Systems Journal, Vol. 41, No. 2, 2002. 18. M. Madhavji, The Process Cycle, Software Engineering Journal, Vol. 6, No. 5, 1991. 19. C. McGowan, L. Bohmer, Model-based business process improvement, 15thInternational Conference on Software Engineering, IEEE Computer Society Press, 1993. 20. D. Miers, Business Process Engineering, C-T Colin, Kogan Page, London, 1996. 21. OMG, Unified Modeling Language Specification, Version 1.5, formal/03-03-01, 2003. 22. OMG, Unified Modeling Language: Superstructure, Version 2.0, Final Adopted Specification, ptc/03-08-02, 2003. 23. OMG, Business Object Management Special Interest Group (BOMSIG) Glossary of Terms, 1995. 24. M. Ould, Business Processes, Modeling and Analysis for Reengineering and Improvement, John Wiley & Sons, 1995. 25. A. Scheer, ARIS – Business Process Modeling, 2nd edition, Springer, 1999. 26. T. Reenskaug et al., Working With Objects: The OOram Software Engineering Method. ManningPublication Co., 1996. 27. B. Singh, G. Rein. Role Interaction Nets (RINs): A Process Description Formalism, MCC, 1992 28. D. Taylor, Business Engineering with Object Technology, John Wiley & Sons, 1995. 29. R. Turner, Strategy for Developing an Integrated Role Theory. Humboldt Journal of Sociology and Religion 7: 123139, 1979. 30. M. Uschold, M. King, S. Moralee, Y. Zorgios, The Enterprise Ontology, The Knowledge Engineering Review, Vol. 13, 1998. 31. E. Verharen, A Language-Action Perspective on the Design of Cooperative Information Agents, CIP-Gegevens Koninklijke Biibliotheek, 1997. 32. T. Walford, Business Process Implementation for IT Professionals and Managers, Arthech House, Norwood, MA, 1999. 33. E. Yourdon, Modern Structured Analysis, Prentice-Hall, Englewood Cliffs, NJ, 1989. 34. Workflow Management Coalition, The Workflow Reference Model, 1995