3Goals and Roles:
The Essentials of Object Oriented Business Process Modeling
Elizabeth A. Kendall
kendall@rmit.edu.au, kendall@info.bt.co.uk
Intelligent Business Systems Research, BT Laboratories
MLB1/ PP12, Martlesham Heath, Ipswich, IP5 3RE ENGLAND
This paper maintains that analysis needs to emphasize what a business or system is trying to achieve. Further, once goals have been captured and structured, they should be partitioned and assigned to roles that appear in role models. As roles can be played by objects, systems, or people, this results in a unified approach to object oriented business process modeling.
1.0 Introduction
Object oriented business process modeling should answer the following questions:
Section 2 answers questions Q1 and Q2 by capturing and structuring goals. The approach is based on use cases [4] that emphasize goals, termed goal cases. The approach presented in section 2 is mature and has been utilized to solve many real problems; it has been written in a full pattern format in [5]. Section 3 presents role modeling as a promising approach to answering Q3 to Q5.
2.0 Capturing and Structuring Goals
Questions 1 and 2 should be addressed by the following three closely related patterns that are based on [2, 4, 7, and 8].
2.1 Capturing Goal Cases
Problem
During analysis, there is often a detailed set of requirements that are of varying levels of detail and fairly informal, including processes, activities, and many variations. Many requirements are stated in task oriented scenarios, with a focus on activities and detailed steps. In addition, the purpose of each activity is not explicitly defined and objectives are obscured.
In the face of these difficulties, it is the responsibility of the analysts to capture and emphasize what is important. Analysts must also identify a foundation for the requirements model, but the tasks and activities employed by a business are variable.
Solution
A requirements model should concentrate on the value added work, which is the goal or objective, at any point [8]. In analysis, goals should be distinguished for each set of scenarios [2]. You should base your model on what is to be achieved rather than how activities are to be carried out. Goals are less likely to change than activities and processes as they reflect aims and objectives, which are more stable.
The Capturing Goal Cases pattern begins by extracting scenarios. Goal statements for each scenario are ascertained by posing the question, "What is the objective of this scenario?". Relationships between scenarios and goals must be preserved so that requirements are traceable. Each use case [4] must therefore be related to a particular goal. To emphasize this perspective, we have coined the term goal case.
2.2 Structuring Goal Cases
Problem
It is difficult to determine when to start and when to end a given scenario in a goal case. There are different types of scenarios and goals, and there are hierarchical and other relationships between them. Some scenarios are central and always occur, while others are conditional exceptions. Levels of detail in scenarios and goals must be preserved.
Solution
Scenarios and related goals should be structured so the main sequence of interaction, variations, conditional exceptions, and subordinate details can be distinguished from one another [4]. Goal cases should be structured so that all interactions in a given goal case pertain to the same goal, continuing until the goal is achieved or abandoned. At all levels, alternative and extension cases should be considered separately from the main discourse [2]. Placeholders should be established for detail that is expected to appear later.
2.3 Avoiding Redundancy: Goal Cases as Objects
Problem
After goal cases have been structured, there may be duplications. That is, a subgoal and its relevant scenarios may appear in more than one location in the model. Redundant goal cases will be hard to maintain, and duplication bloats the model.
Solution
Each goal case should be treated as an object. Redundant goals and actions should be promoted to a high level object, utilizing inheritance to bring common factors into subordinates. Further, any repeated goal cases can be viewed as instances of the same class. This leads to a goal case hierarchy diagram, per Figure 1. In the diagram, each node is a goal case, and duplication is avoided. Numbering is used to preserve all relationships, and a dashed line (and a letter suffix) indicates a conditional exception.
Figure 1: Goal Case Hierarchy Diagram
2.4 Resulting Context
The solution obtained by applying the three patterns leads to a goal driven approach rather than one based on tasks and activities. Further, a goal centric approach to analysis leaves all options open for design and implementation.
Additional patterns are needed for goal based analysis to address the following:
3.0 Partitioning the Goal Hierarchy Diagram: Roles and Role Models
3.1 Overview
The goal hierarchy diagram needs to be partitioned so goals can be assigned to people and objects. The results of the partitioning will provide answers to questions Q3 through Q5 in section 1. A unified approach is needed, one that encompasses people, processes, objects, and resources.
Roles and role models [1, 6, 9, 10] are relatively new abstractions in object oriented software engineering that represent powerful approaches to these issues. Roles have also been widely used in business process modeling [7]. Work at BT aims to clarify, integrate, and extend the role and role model concepts and notation from object oriented software engineering and business process modeling. Role model patterns are also being identified.
Role models respond to the following needs:
3.2 Motivation
There are a few approaches to role modeling available in the literature [1, 6, 7, 9, 10]. The summary presented here is closely based on [1] and [10].
A role model is very similar to a collaboration diagram in UML, which effectively captures the interactions between objects involved in a scenario or use case. However, a collaboration diagram is based on instances in a particular application; its potential for reuse and abstraction is limited. Further, it is just one perspective of an overall UML model; usually it is subordinate to the class diagrams.
Class diagrams adequately address information modeling, but not interaction modeling [1]. This is because classes decompose objects based on their structural and behavioral similarities, not on the basis of their shared or collaborative activities and interactions.
This is where role models come in. A role model describes a system or subsystem in terms of the patterns of interactions between its roles, and a role may be played by one or more objects or some other entity (that is left as a design or implementation decision). A role model can be generalized, specialized, or synthesized from other role models; alternatively, one role model might constrain or limit another. A role model, or usually a set of role models, is then instantiated in a given application, and objects are assigned to play one or more roles. Role models are therefore "first class objects."
3.3 Example
The example is based on [10], and the application is a scheduling system for a shipyard. At the shipyard, a project is made up of a sequence of activities that must be scheduled; there are a limited number of resources.
The class diagram is shown in Figure 2a, while a collaboration diagram appears in Figure 2b. The class diagram does not reveal much at all about the system's dynamics. Individual objects appear in the collaboration diagram, and, through messaging, they enact the scenario.
Figure 2a: Class Diagram
Figure 2b: Collaboration Diagram
The collaboration depicted in Figure 2b is a pattern of general applicability; it represents the interactions between a Client, a Handler or Node, and the Predecessors and Successors of the Node. A name for it might be Chain of Activity, and a role model representation of it is shown in Figure 2c. In Figure 2c, a rounded box is a role, and the small circles represent ports or channels between roles. The objects in the application play the various roles, as indicated by the dashed arrows.
Figure 2c: Role Model
3.4 Role Relationships
Once you have a base role model, you can build on it to form new models. One role model may be an aggregate of others. Also, a new role model may be derived from one or more base models; in this case, the derived role must be able to play the base roles. Combined roles must be addressed in a system specification. Synergy can make a combined role more than just the sum of the parts.
An example of this is the Bureaucracy pattern [11]. This pattern features a long chain of responsibility, a multilevel hierarchical organization, and centralized control. This pattern can be constructed by bringing together the Composite, Mediator, Observer, and Chain of Responsibility patterns [3] [11], which involve eighteen roles in total. However, there are only six roles in the Bureaucracy pattern because the resulting compound pattern is more than just the sum of the individual patterns
3.5 Summary and Future Effort
Chain of Responsibility, Mediator, Observer, and Bureaucracy are all role models that are relevant to business process modeling. They can be used to model business systems comprised of people, organizations, systems, and objects. Other relevant role models can be found [1, 6, 7, 9, 11]. Patterns are needed for identifying roles and role models that are relevant to business process modeling, and a role model catalog is under development at BT as a first step.
Whereas static role models have been presented here due to limitations of space, it is anticipated that role dynamics [6] will be a fruitful area for modeling changing business processes. Here, roles can be transferred from one entity to another, or follow a certain sequence. This may be valuable for modeling mobility.
4.0 Acknowledgements
The author acknowledges the support of the following students at the Royal Melbourne Institute of Technology: Nilesh Panvalkar, Satya Kalikivayi, and Uma Palanivelan.
5.0 References