Business services modeling

Skip to main content

Country/region
[select ]
All of dW -----------------   AIX and UNIX   Information Mgmt   Lotus   Rational   Tivoli   WebSphere -----------------   Architecture   Autonomic computing   Java technology   Linux   Multicore acceleration   Open source   SOA & Web services   Web development   XML -----------------   dW forums ----------------- alphaWorks ----------------- All of IBM

Home
Solutions






Services






Products

















Support & downloads










My IBM







 
developerWorks
In this article:
Introduction
Modeling techniques
Business services modeling
Example
Using the Business Services Model in RSA
The WBM Business Process Model as a UML2 Business Services Model
Business use cases
BPM to BSM mapping
Conclusion
Resources
About the author
Rate this page

Related links
Rational technical library
Architecture technical library
The Rational Edge



developerWorks  >  Rational | Architecture  >
Business services modeling
Integrating WebSphere Business Modeler and Rational Software Modeler

Document options

Print this page

E-mail this page

Discuss
Rate this page

Help us improve this content
Level: Intermediate
Jim Amsden (jamsden@us.ibm.com), Senior Technical Staff Member, IBM
27 Dec 2005
Business process models are traditionally used to specify business operational requirements necessary to meet business goals and objectives. These business process models are often directly executed in a workflow based runtime platform. In other cases the business processes or tasks within them may benefit from other architected solutions that facilitate integration with business services providers or to enable better reuse. Business Services Modeling helps bridge the semantic gap between business requirements and the architecture of IT solutions that are intended to meet them.
Business Services Modeling provides a formal relationship between business process models and the model elements that realize them by treating each business process as a contract. This contract specifies service providers playing roles in a collaboration fulfilling responsibilities choreographed by rules for how the roles interact in order to achieve some business objective. Contracts provide a clear separation between specifications of what has to be done from the many possible ways of doing it.
Business Services Modeling also forms the foundation for the integration between IBM’s® WebSphere® Business Modeler and Rational® Software Architect (and UML) and new Rational® Unified Process (RUP®) business modeling guidelines to better support Business Driven Development.
Business application development often starts with business process modeling to discover and document the key business requirements necessary to meet business objectives. Some applications can be implemented directly as process models using platform runtimes such as WebSphere® Process Server. Tasks in these processes can be implemented using a variety of techniques. However, there are many cases where simple functional decomposition leading to workflow based applications are not enough. In these cases other architectural styles may be used to develop applications in order to better manage complexity, achieve more reuse, and to facilitate change. Business analysts often specify the system functional requirements using process models while developers prefer to use object or service modeling to specify implementation models. How these different world views are reconciled and kept in sync as the applications develop in the face of changing business requirements is not well understood and can result in cost overruns and applications that don't meet customer needs. The problem is that there is no well-defined relationship between process models and object models, reflecting yet again the business/IT gap and resulting in poorly integrated development tools.
Integrating business and object modeling tools has been a challenge because of conflicting perspectives and lack of formal semantics. Traditional RUP approaches use business models as a means of discovering object models and then rely on wholesale model refactoring during object-oriented analysis, design and implementation. Without rigor, the connection between the business use cases and these object models can get lost. This often leads to significant reconciliation and traceability issues as the business requirements change, implementation technologies change, and existing applications are integrated.
This article describes a new approach incorporating the best of both process and object modeling techniques by treating business process models as service contracts specifying what object models must implement. The Business Services Model (BSM) is a dynamically created UML2 model of a service specification between business clients and IT implementers. Figure 1 shows the Business Services Model as a mediator between the business requirements expressed in process models and any implementation, including object or service-oriented implementations.

In the BSM, business process models are viewed as collaborations in UML2 that specify the participants in the processes, what they are responsible for, and the protocol for how they interact. These contracts specify everything clients requiring business services must know to use those services, and everything implementers must know in order to provide functionally compliant implementations. Business analysts can specify business functional requirements using business process models. Then developers can view these process models as component and/or service contracts that they are free to implement the best way possible while addressing software IT concerns. If the business processes change, then the services specifications change and developers will see the new functional requirements directly in their object modeling tools. If the implementation changes, clients are not effected because the contract they see does not change.
As a result, rich object-oriented or service-oriented analysis and design models can be directly connected to the business processes and tasks they implement, making the models easier to understand and verify, while providing full life-cycle traceability. It is no longer necessary to transform the process model into an object model in order to achieve the benefits of an object or service oriented implementations. The service specifications in the BSM act as a mediator between business requirements and implementation models of those requirements to help bridge the business/IT gap.
The rest of the document describes the details of how the BSM provides integration between business and process modeling, and how this integration is supported in IBM® Rational® Software Modeler's (RSM) and IBM Rational Software Architect's (RSA) integration with IBM® WebSphere® Business Modeler (WBM). It is no longer necessary to export business models out WBM and import them into RSM. Instead RSM can directly open WBM business models and view them as object-oriented business, service, and/or component specification contracts. Developers can then use all the facilities of RSA to implement the service specifications. References from the implementation models to business model elements through the specifications are automatically preserved. Changes in the business model are immediately visible in the object models so that developers can see what implementation changes are required. Full traceability between the implementation models and the business models is guaranteed because there is no import/export between the modeling tools, and no copies of models to get out of sync.
Creating and using a BSM is described by using a simple development use case to guide the development of an example using WBM and RSA. Throughout the article we refer to business services specifications in the business services models as contracts specifying the relationships between roles in the business process and how they have to interact in order to fulfill some business requirement. These concepts are based on ideas from Contract Based Development and ROOM that are finding a resurgence in service oriented architectures as well as collaboration and component modeling in UML2.


Back to top
Any software application has to have a specification of what it does, and an implementation for how it does it. Models can provide a relatively high-level way of describing both. There are two basic styles of software modeling in common practice today: business process modeling and object modeling. We don't want to get into a big discussion here about the relative merits of one modeling or programming style over another. That could take a while, and probably wouldn't convince anyone that the method they don't know is better than the one they do know. The truth is that process and object modeling both have their strengths and weaknesses. The challenge is to figure out how to use both to their best advantage, avoid their deficiencies, and reduce the overall work required to specify and build software systems.
The following subsections summarize some different modeling styles in order to present common terms that set the stage for their integration. This is not intended to be a complete treatment of business process, object, component, or service modeling. Nor does it go into a lot of detail about their relative merits. Instead it focuses on what we need to know in order to explore how they can be integrated.
A business process model consists of a set of processes perhaps organized into catalogs. Each process represents the business operational requirements necessary to achieve some business goal or objective or functional and nonfunctional requirements specified in a business use case. A process contains a number of tasks linked by either control or data flows that choreograph the tasks in the process. Tasks represent some unit of work in a process whose details are not included in the model. A task can invoke another process, invoke a service provided by others (inlcuding manual services), invoke a local or global function defined as part of the process model, or perform any other calculations that are indivisible from the point of view of the process modeler. These processes are about the business, not necessarily about any automated software process. Business processes are another, commonly practiced way of capturing business requirements. There are many other techniques including business rules and business use cases that can also be used. However, in this article we restrict our view to business process models because of their simplicity and common use.
Tasks can be assigned resources that are required, perhaps at a particular location, for their completion. Often, at least one of those resources is a role resource that specifies what role in a business organization is responsible for performing the task, or what services some service provider must be able to perform. Some tasks are manual and are performed by people who have sufficient skills and are qualified to play the role assigned to the task. Other tasks can be automated and are performed by a component of a software application that plays the role. The process choreographs the tasks performed by roles required to achieve the process's objectives. To assist in specifying this choreography, communication protocol, or orchestration, the process may contain other control and loop nodes for selecting alternative execution paths, branching and merging parallel flows of control, and iteration.
Business process models appeal to business analysts because they can be relatively simple and focused on specific, identifiable tasks that result in clear business value. We are all very familiar with following a sequence of steps or a recipe to achieve some end result. It is very easy to capture existing or anticipated business processes in process models because these models directly reflect the steps in the business.
There are workflow-based systems, such as WebSphere Process Server, that can execute process models directly. This can be an effective solution for simple business processes. But it tends to break down as the complexity of the business processes increases, as the processes change to address new business requirements, or as the processes are decomposed and refactored for reuse. Large applications based on process models (and functional decomposition) can be hard to understand and expensive to maintain because the state of the application is distributed in unpredictable ways throughout the system, and implementations are tightly coupled through calls/called relationships. This coupling and complexity also makes such applications difficult to reuse and integrate with other applications.
Object-oriented technology (OOT) introduces the concepts of identity, encapsulation of state and behavior, inheritance and polymorphism, and communication through messages. OOT greatly reduces the complexity and maintenance costs of software systems, and facilitates reuse.
OOT has been shown to be useful in reducing system complexity, managing change, and facilitating reuse. In some situations, the business processes might benefit from using an object-oriented (OO) implementation. But what is the relationship between the business processes and the business requirements they represent, and OO implementations? Do you transform the business process models into an OO implementation by using them to help discover domain objects that interact in some way to accomplish the same business results?
There's much in the literature that tries to do this, but with limited success. Since there is no formal relationship between business process models and object models, the transformations are often unpredictable, incomplete, and cannot be reproduced. If the business model changes, it is often very difficult to reconcile those changes with the object model, because traceability is also unpredictable. The manual translation of business process requirements through use case analysis, OO analysis, design, implementation, test, and deployment can result in a significant gap between the original business requirements and their deployed implementation.
Business systems can be modeled directly using OOT, but most business analysts have difficulty seeing their business processes when they are burried in a set of collaborating objects. How could process and object modeling be integrated so you can get the benefits of both for the business analyst and developer? This article will explore this in the following sections.
Modern enterprise applications have to address many other concerns including distribution, persistence, security, integrity, integration, and flexible deployment. These concerns all arise from introducing the software domain. Software applications are also influenced by the increased demands business place on their IT organizations for applications that do more, take less time to build, are available everywhere, are easier to change to meet new business opportunities, and are easily integrated with applications from other business partners. Oh, and they have limited budgets and limited developer skills too! OO languages and development tools can be used to build complex distributed business applications that address all these concerns. However, object-oriented technology can result in highly coupled systems through inheritance and object references that may have poor performance and inhibit flexible deployment. This coupling stems from clients knowing too much about how services they use are implemented.
Component or service based development extends traditional OO development by providing a clear separation between specification and implementation. This separation reduces the coupling between parts of the system making it easier to reuse and deploy them in other contexts. Components can be wired together at development time, deployment time, or even run-time by using services that look up components providing necessary functions. The implementation of a component can be substituted with a new implementation without effecting clients as long as the new implementation realizes the same component specification.
A component specification defines a contract between clients requiring services, and implementers providing services. The contract is made up of two parts. The static part, or usage contract, specifies what clients must know in order to use provided services. The usage contract is defined by interfaces provided by a component, and required interfaces that specify what the component needs in order to function. The interfaces contain the available operations, their input and output parameters, exceptions they might raise, preconditions that must be met before a client can invoke the operation, and post conditions that clients can expect after invocation. These operations represent features and obligations that constitute a coherent offered or required service.
The second part of the contract, the realization contract, specifies what implementers must do in order to satisfy the contract. That is, the realization contract specifies any communication or state-based protocol that must be realized by an implementation, or any particular orchestration or choreography of services that must be maintained. Notice that this is the same thing that is modeled by a business process. We'll explore this in more detail in the next section.
The best way to model contracts in UML2 is to use a Collaboration. The usage contract is specified by the collaboration roles acting at the participants in the collaboration. The types of these roles, often service interfaces, specify what services any service provider playing the role must provide. Connections between the roles indicate interaction between roles and the ports through which they communicate. The collaboration can contain a Behavior, an Activity, Interaction, StateMachine or ProtocolStateMachine that specifies the realization contract.
Contracts can also be modeled as «specification» Components. The interfaces realized by the component define the provided interfaces while «use» Dependencies are used to specify required interfaces. Alternatively, the ball-and-socket notation can be used to show provided and required interfaces. The realization contract can be modeled as a Behavior added to the «specification» Component. This behavior could be an activity, interaction, or state machine, and would express the orchestration of actions performed by implementers of the component. A component implementation is shown as an «implementation» Component with a «realize» dependency pointing to the «specification» Component defining the contract. The same «specification» Component could be realized by many «implementation» Components, each with different architectural and nonfunctional characteristics.
Whether collaborations or specification components are used to model a contract is a matter of choice. We use collaborations in rest of this document because that can also represent patterns of interaction between participating roles that can be instantiated for many concrete situations. Collaborations can elide away unnecessary detail by focusing on only those aspects of the problem domain involved in a particular business contract. Collaborations also provide a convenient way to model how specific service providers play roles in an implementation component through a CollaborationUse that binds parts of the component to the collaborationRoles in the Collaboration.
Business use cases can also be used to provide a higher level view of the business requirements realized by a business services specification and a place to specify nonfunctional characteristics. These business use cases are realized by the collaboration or specification component representing the contract to indicate the business requirements addressed by the collaboration.


Back to top
So how do the business functional requirements expressed in the business process model relate to an OO implementation? The answer is through service specifications or contracts derived from the process models that specify what the implementation must do, but not how to do it. These contracts are called Business Services Specifications because they are derived directly from business processes. Not all of these service specifications have to be implemented by some software system. But for that subset of the business processes that are automated, the service specifications mediate between the business operational requirements and their software implementation model by providing a formal, service-oriented, and verifiable specification of what those implementations must do in order to realize the requirements.
Each process in the business process model is viewed as a UML2 Collaboration. The collaboration roles are derived from the role resources assigned to perform tasks in the process. A role is viewedas a UML2 Interface whose operations, and their signatures, are derived from all the tasks assigned to that role in all the processes in which it participates. The parameters of the operation are derived from the inputs and outputs of the corresponding task. This provides the complete usage contract for the business process by specifying the participating roles and all their required interfaces.
The realization contract is an Activity behavior added to the Collaboration. This activity is derived directly from the business process itself. Each task in the process becomes an operation invocation in the activity. The target instance for this operation invocation is an instance of the interface corresponding to the role the task is assigned to. Most other process modeling elements correspond closely to model elements in a UML2 activity making the transformation of a business process to an activity straightforward.
Each process can also realize business use cases that specify thebusiness requirements realized by the business process. The actors participating in this use case are business actors derived from the roles and service providers participating in the business process. The business use case is also realized by the collaboration indicating that the contract specifies how the requirements must be met by implementations.
It is these formal relationships that guide how tools should be integrated to enable end-to-end development that meets business needs. There is no need for additional, non-standard dependencies, nor is there any missing traceability between the business process models and the UML2 Business Services Models. This is because the BSM is a view of a business process model, not a separate, persisted model in its own right.
The business service specifications can then be realized by any number of Classifiers that contain a CollaborationUse which bind their parts (properties and association ends) to the roles in the collaboration, thereby providing an implementation that fulfills the specified contract. There are no constraints on how these classifiers are organized. An architect can design a system that addresses other IT requirements specified in a system use case, architectural, and/or nonfunctional concerns over and above the requirements specified by the business service specifications. As a result, there is a large degree of freedom about how the implementation is modeled and transformed into running code. However, in the final implementation, the required interfaces specified in the contract, and generated from the required roles in the business process model, will be realized somehow, and with behavior that is consistent with the business process that specified the realization contract. As a result, the gap between the business requirements and an OO IT implementation is effectively closed in a formal, well-defined, deterministic, and repeatable way.
Once the system boundaries have been established by determining what portions of the business operational requirements are to be automated with software components, you can start developing an implementation that realizes the service specifications. Such an implementation may start with system use cases which model additional system requirements (such as task details, architectural and nonfunctional requirements). System use cases provide a convenient way to include IT concerns or design constraints into the system without commingling them with the buisiness concerns specified by the service specifications. The system use cases don't directly connect to the business use cases, because they deal with a different set of concerns. Instead, they link indirectly through the implementing classifiers and the service specifications they realize.
The Business Services Model includes specifications for all processes in the business process model. A BSM corresponds roughly to a computation-independent model (CIM) in the OMG Model Driven Architecture (MDA) framework. It specifies what the implementation must do, but now how it does it in terms of applications, software architecture, middleware, or runtime platforms. The contract implementations correspond to OMG MDA platform independent models (PIM) as they specify what business contracts are implemented and how.

In the RUP, Business Use Case modeling "defines a set of business use-case instances in which each instance is a sequence of actions that a business performs that yields an observable result of value to a particular business actor". That is, the RUP takes the view that a use case describes the requirements for some system providing value to actors as users of or participants in that system. That value can be described in business goals and objectives the business use case realizes. Business process models can then specify the business operational requirements necessary to meet the requirements of those business use cases.
The Business Services Modeling formalizes the relationship between business operational requirements and their realizations. This can help transition business process models into business services models that allow more flexible implementations that fit better with SOA runtime platforms. The business service specification provides another view of the business process that also realizes the same business use cases. There can be many different and perhaps evolving ways to realize that services contract. This separates the concerns of business objectives and requirements, from business operational requirements necessary to meet those objectives, from business services specifications specifying what software systems automating (portions) of those operational requirements have to do, from the implementations that actually do it. This allows each specification/realization pair to separate concerns while at the same time maintaining a formal, traceable relationships or integration between them.
It is these formal relationships that guide how tools should be integrated to enable end-to-end development that meets business needs. IBM calls this "Business Driven Development" as it drives the system development from business goals and objectives down through process models, service contract models, implementations, deployments, etc. that meet them. Then the deployed systems can be monitored to collect information on Key Performance Indicators to see if the goals and objectives were met, and provide information necessary to evolve and support new business opportunities.
The RUP takes a successive elaboration view of development from requirements, through analysis, design, implementation, and test. Business Driven Development specifies one way this elaboration can be achieved through a service-oriented view that says at any point in the development lifecycle, you can model a service contract that captures what the stakeholder/modeler is concerned with, separate from how those concerns might be addressed or realized. This services specification or contract can then be realized by some other model that introduces additional concerns required by the realization. This realization then becomes (or can be viewed as) a contract for recursive realizations that introduce yet other concerns until all those necessary to meet functional and nonfunctional requirements have been addressed. This separation of concerns is formalized through contract based development as a means of performing successive elaboration where there is a formal traceable connection between the elaboration steps. This approach may facilitate use of emerging SOAs and provide more formal and repeatable relationships between levels of abstractions and parts of the system. Perhaps this provides another way of looking at OMGModel Driven Architecture. The platform is only one set of concerns, there may be many others involved in the business itself and architectural frameworks for applications that support the business. It is this separation and integration of concerns that is at the heart of MDA.
The RUP has been updated to include some of the concepts in Business Driven Development and Business Services Modeling. See theRUP Plug-In for WBI Modeler.


Back to top
The easiest way to understand business and object modeling integration is through a concrete example. This section demonstrates the integration by using the WBM/RSM integration to create a simple concrete example based on a typical business driven development use case.
The example is a portion of the IBM Insurance Application Architecture (IAA) model that is commonly used for demonstrations. It deals with processes that establish and administer insurance claims.
To frame the example and show how business and object modeling integration could be used, you'll follow a simplified version of the Business Driven Development process. This process is not intended to address all aspects of business process modeling, object modeling, or application generation and deployment. It is intended to give a broad overview of those subjects in the context business process and object modeling integration through a simple, but typical end-to-end development process.
The steps of the simplified business driven development process are: Capture business goals and objectives Capture business use cases that specify requirements necessary to meet the goals and objectives Discover and capture key business processes that realize the business use cases Simulate the as-is and to-be business processes and refine as necessary Determine opportunities for software automation Realize the Business Services Model using some chosen architectural pattern Generate and deploy the service implementation Generate the process choreography Bind the tasks with service implementations
 
Steps 7 through 9 are beyond the scope of this document and will be discussed in future documents on Business Driven Development. The following sections examines steps 1 through 6 in more detail showing how to use WBM and RSA to model and implement a business application.
Business Driven Development starts by capturing the business goals and objectives that business executives are trying to achieve. Without these goals and objectives, there's no way to know if the software systems actually contribute business value or not. It would be impossible to know what return on investment was realized from the development project, and therefore difficult to justify additional budget for enhancements or other follow-on work.
To be effective, goals and objectives must be SMART: Specific, Measurable, Achievable, Realistic, and Time-bound. SMART goals can be quantified and verified. Each goal should have one or more Key Performance Indicators (KPIs) that specify what information must be captured in order to know if the goal is being achieved. Later on in the development process we can use these KPIs to design an observation model, which can be used to specify how deployed software applications are to be monitored to collect data necessary to verify that they meet business goals.
Business goals and objectives and their KPIs can be captured in IBM® Rational® RequisitePro® databases. Then the business processes, business use cases and service specifications (described below) can be linked back to the goals and objectives they are intended to achieve. This provides traceability between the goals of the business, the business processes that realize them, and the services that realize business processes.
Modeling goals and objectives is outside the scope of this simple example, which is intended to focus on the relationship between business processing and component or service modeling. However, it is important to understand where this important activity fits into the overall development process, in order to ensure you develop the right things the right way. Goals and objectives also represent the root contract in our recursive specification/realization pairs that address all the concerns necessary to realize them.
Once the goals and objectives have been documented, business analysts then turn their attention to the requirements necessary to meet them. These requirements can be captured in Business Use Cases in RequisitePro, and linked to the business goals and objectives they are intended to achieve. Business use cases describe an interaction between external participants and the business functional requirements that produces value. Business use cases are an effective means of capturing these high-level functional requirements becuse of their simplicity, informal nature, simple andwell known tool interfaces (often Word documents) and represent a low barrier to entry for business executives and analysts.
Modeling business use cases is also outside the scope of this simple example, but is discussed here to show their important relationship to businss goals and objectives on the one hand, and business processes that realize the use cases on the other. This is an important bridge between formal and informal modeling that often captures important functional requirements known by key stakeholders in the business.
The next step in your development process uses WBM to discover, design and/or document key business processes that realize the functional requirements captured in the business use cases. This step is not concerned with software, or which processes or tasks will be automated. Instead it focuses on the business, business requirements, and observed or anticipated processes that meet those business requirements. Often these processes are discovered by observing specific scenarios that occur in the business. New processes are designed to improve efficiency, exploit new market opportunities, or integrate previously separate business units.
Process modeling focuses on specific business processes or operational procedures that are or should be performed in order to support the business, who is responsible for tasks in the process, what resources are required, how much executing the process will cost, and how long they take. Modeling business processes consists of answering a number of questions about the business: What are the business requirements we are trying to realize? What tasks need to be performed in order to achieve the objectives? How are those tasks orchestrated? What roles in the organization are responsible for performing each task? What are the required skills and permissions? What other resources are required to fulfill the task? Where are those resources located and what do thay cost? How long will each task take? How much will they cost? What information is required in order to perform the task? Where does this information come from and where does it go after the task is completed? How is the information changed by the performance of a task? How does the business organization support the required roles? What other services are required that must be provided by others?
 
This example won't answer all those questions, but will instead take a sample business model that has already been discovered and validated. The IAA model contains processes that result from applying these questions to the problem of handling insurance claims. The overall organization of the model is shown in the WBM Project Tree in Figure 2.

The business data for this set of processes is organized in the Business Items catalog shown in Figure 3.
Each business item can have any number of typed attributes -- some of which are primitive types, and others are non-primitive -- indicating associations between business items. The associations are shown as expandable business item attributes. Expanding the element by clicking on the plus sign shows the properties of the associated business element.

Figure 3 shows a list of the business items that are used in the IAADemo business model. ClaimFolder is selected and opened to show all the information that is collected about a claim. Notice that ClaimFolder has DataStructure as a parent template. A template is used to specify common attributes that are to be included in business items whose parent is the template.
In WBM, these business items represent information exchanged between tasks and processes in the process models. They may correspond directly to entities in the business domain, but often do not. Instead they represent subsets of, or a view of, the business domain data that is used in the context of a particular message or data exchange between tasks in a business process. Persistent business domain objects are more often modeled as repositories in the business processes. We’ll discuss this further in the context of UML2 services, persistent entities, and data transfer objects.
Figure 4 shows a typical business process. The Administer Claim process handles a particular claim throughout its complete lifecycle. The process has an input called claimContainer of type ClaimContainer, one of the business items described above. This input contains all the data required by the process. Different tasks in the process use and update this data.

In the Administer Claim process, the Notify No Coverage task has this claim container as an input, and outputs the same data item. This task is assigned to a Claim Processor, which is a role responsible for performing the task.
The resources in the model shown in Figure 5 define the roles played by either people or other business systems, and any other resources required for task completion.

Business model simulation can be used to verify that the business models perform their required functions, have sufficient resources, and realize the intended business objectives. Simulation can also be used to determine bottlenecks, and to help optimize business processes to minimize costs or maximize services.
Simulation data is not part of the specification of a business process, and is therefore not visible in the UML2 business services model. So this example will not go into further detail about how to simulate and update business processes. There may be opportunities for further integration between WBM and RSA that use simulation data to, for example, create test cases or provide information for load balancing on deployment.
Once the business processes have been completed (at some desired level) and verified, the customer, business analysts, architects, and developers negotiate to determine which tasks in the business model are candidates for software automation. These decisions are often based on business objectives, costs, time-to-market, and expected application lifetime. The result of this step is a list of processes, tasks, and/or services that are to be implemented by some supporting software system, and as such represent the initial requirements for that system.
The business processes are used to define the Business Services Model, which specifies the contracts between roles participating in the process, and the implementations of those processes and tasks. This is the key concept integrating business process modeling and object modeling. WBM is used to create the process models that capture the business requirements used to specify the contract implementations -- modeled in UML2 and built using RSA -- that must be fulfilled. This integration is formalized in the specification and realization of those contracts in UML2, as described previously and shown in the following sections.
Once the contracts have been fulfilled, it is a relatively simple matter to generate the process choreography as a Business Process Execution Language (BPEL) process using WBM, and then bind the tasks (invocation activities in BPEL) invoked in these processes to their corresponding service implementations produced by RSA. This is easy because RSA implementations implement the contract specified by WBM, keeping the implementation artifacts in sync with the business processes.
Using WBM and RSA or RSM requires WBIM version 5.1.1.2 or later, RSM or RSA version 6.0.0.1 or later (6.0.1.1 is preferred). Use IBM® Rational® Product Updater (RPU) to install and apply any required updates and features. You can use either RSM or RSA to view the business services model. RSM can be used to create analysis and design models of the service specification implementations. RSA provides many additional tools that can be used to generate code that implements the design models. This example uses RSM and RSA interchangeably for the analysis and design models.
You are now ready to implement some of the tasks chosen for software automation. The first thing to do is to create a new (or open an existing) RSM model that will be used to model the design and implementation artifacts. In this example, you’ll build the implementation models in an Eclipse modeling project called IAADemo Design.
The design model needs to be a separate model from the business process model for a couple of important reasons. The first is to keep the implementation completely separate from the specification. This makes it easier to provide different implementations of the business process contract at different times for different platforms, or implement and deploy only a portion of the automated business processes in phased releases.
Another reason for using a different model is that the business process model represents the contract that implementers must implement. It would be inappropriate for implementers to change this contract without renegotiating with the business analysts to change the business processes in response to newly discovered requirements. Otherwise there is a risk that the business requirements will not be met. Therefore, the WBM business process model is read-only when viewed as a contract from RSA in order to ensure the contract is not inadvertently changed. However, it is still possible to use RSA to create diagrams to view various parts of the business process contracts. These diagrams just need to be created in a different model that references the WBM business model.
In order to implement the tasks in the business process model, you have to have the contracts specifying what clients have to know in order to use the tasks, and what the tasks are expected to do. You get this information from the WBM models viewed as Business Services Models in UML2. To access the model, simply import the WBM project into your RSA workspace using File -> Import -> Existing Project Into Workspace or checkout from a versioning repository. When using an existing project, the files are not actually copied. Rather, a new modeling project is created in the RSA workspace that contains exactly the same physical files as the WBM project. Any changes to these files by WBM are immediately reflected in the RSA project as soon as the project is refreshed. The sharing of projects across workspaces is required when WBM and RSA are installed as separate products and do not run in the same workbench or share the same workspace. WBM and RSA appear as external applications to each other, but can share the same files.
Once the WBM project has been imported into an RSA project, its resources can be viewed by the RSA Model explorer, as shown in Figure 6.

The contents of the IAADemo project shown in Figure 6 don't look the same as the Project Tree view from WBM in Figure 2 previously. This is because you are looking at the actual files in the project using the RSA Model Explorer. These files are in the WBM IAADemo project, but are hidden by the Project Tree view. You can see them in WBM by using the Navigator view. A subsequent release of RSA will show the WBM process model in a more logical way in the RSA Model Explorer.
If necessary, switch to the Modeling perspective and open the business services model by double clicking on file resoures.XMI. You can also select resources.XMI, right-click, and select Open, or Open With -> Model File Editor. RSA will display the contents of the business process model translated into the business services model in UML2, as shown in Figure 7. Note that this file can only be opened as an RSM model from the Model Explorer. It will be opened as a text file from other views such as the Navigator view.

The file (or Eclipse resource) resources.XMI represents the complete WBM IAADemo business process model. Opening this file automatically translates the file to the UML2 Business Services Model so it appears like any other UML2 model in RSA or RSM. This UML2 model does not need to be saved, although it is possible to save the business services model as an RSA model with a .emx extension using File -> Save As. However, the WBM business process model is read-only in RSA. It is not possible to make any changes to the translated UML2 model and save them back to the WBM resources.XMI file. Such changes would have to be saved in a separate .emx file using File -> Save As and would result in a copy of the business process model. This is not the recommended practice because it will result in synchronization problems between the WBM and RSA copies of the model. This is why the WBM to RSA integration does not export the model out of WBM and import it into RSA.
The recommended practice is to treat the business services model as a read-only specification of what has to be implemented in RSA. The specification can only change through negotiation with other stakeholders, and these changes are all done using WBM. Anytime the resources.XMI file is opened, the translation is re-executed and any updates are immediately reflected in the services model. Note that changes made by WBM while the process model is also open in RSM are not reflected in the business services model until the model is closed and re-opened.
There is little performance penalty for this repeated transformation because it is done when the XMI files are loaded into RSA, just like loading any other RSA model. A custom EMF XMIResource (see www.eclipse.org/emf) is used to load and translate the WBM business process model to the UML2 business services model in a single step. This also allows the WBM and RSA integration to be accomplished without introducing any dependencies between the products. They can actually run in different versions of Eclipse, in different workbenches, and in different workspaces.


Back to top
The business services model, translated from the WBM business process model, can now be used just like any other RSM model. The Model Explorer can be used to navigate the model. You can create diagrams in the design model (not directly in the WBM model because it is read-only) to show any views of the services model any way you want. For example, WBM doesn't support class diagrams, but you can create them on WBM models using RSA by dragging and dropping the model elements onto a class diagram or free form diagram, or by creating a topic diagram. You can visualize the WBM model in a browse diagram. You can use Model Compare to compare the UML translations of two WBM business process models, or two versions of the same model. You can create subclasses of business items, realize collaborations, add associations, integrate with other models, attach RequisitePro requirements, or anything you could do with any other RSA models.
When an RSA model with references to a WBM model is saved, the references are saved as cross-resource references to model elements in the business services model. But this model is not saved as a separate resource, since it is a virtual model translated from the WBM business process model. So what happens to those references? Are they broken? Actually, the cross-model references are handled just like any other reference between RSA models. Open the RSA implementation model, IAADemo Design.emx in this example, and start navigating the model contents. As soon as a reference to another model is encountered, the other model is automatically opened, whether it is a WBM model or another RSA model. If it is a WBM model, then the translation to UML2 is again automatically performed to recreate the business services model as the process model is loaded and the links are resolved.
You can also create RequisitePro links to WBM model elements from an RSA model. These links are resolved the same way as cross-model links. You can create URL comments and attach them to elements in the business services model to provide convenient navigation to supplemental documents describing the business requirements.


Back to top
Now let's walk through the translated business services model contents, referring to the example, to see how the service specifications are created from the business process model.
The package structure of the UML2 business services model shown in Figure 8 is exactly the same as the catalog structure in WBM. This view in the RSA Model Explorer is very similar to the WBM Project Tree view.

Expanding the RootInformationModel, we see the Business items and Data Structures that were in the WBM model as classes in the UML model. These stereotypes are specified in the RUP Business Modeling profile which is automatically applied to the business services model when it is opened. As you can see in Figure 9, the ClaimFolder class has the same attributes it had in the business process model in Figure 3.

Class diagrams are not supported in WBM. But in RSA, you can create a class diagram to show the classes and their superclasses. The business item templates in WBM are viewed as superclasses in the BSM because they represent shared properties. In Figure 10, the DataStructure Template is the superclass of both ClaimContainer and ClaimFolder, and represents properties that are common to both subclasses. Templates have a different meaning in UML2 and can be used to capture instantiatable patterns. WBM does not support templates for business patterns. However, service specification collaborations derived from a WBM business process model can be treated as patterns and instantiated using different CollaborationUses. Alternatively, these collaborations can be converted into contract templates to model rich business patterns.

Notice that you can choose to display attributes with complex types as properties or as associations. ClaimContainer has property CoveringInsurancePolicy which is shown as a property with non-primitive type. ClaimContainer has another property, ClaimFolder, which also has a non-primitive type but is shown as an association. The two notations provide different ways of viewing the same information. You can create class diagrams that organize and display business information in any way you want, including having multiple views for different stakeholders. In particular, you might want to create separate class diagrams for the data exchanged for each service.
The business process model represents the validated business operations that realize the business functional requirements. The processes specify what needs to be done to meet business objectives. In this example you've decided to create a system solution that implements some of the tasks and processes in the process model using object technology. But before you can do that, you need to have the business services model that specifies the contracts the solution implementation must meet. These contracts are rooted in a UML2 Collaboration.
Each business process in the WBM model is viewed as a Collaboration with the same name in UML2, as shown in Figure 11 for the Administer Claim process. This collaboration represents the business service specification or contract that specifies what implementers must do in order to meet the business requirements. The collaboration specifies who the participants are, what they are responsible for, and how they are expected to interact. The collaboration roles (properties of the collaboration) are derived from the role resources assigned to tasks in the process model. The role names are the same as the first required role resource for any task in the process. The role type is the interface corresponding to the role as described below. The collaboration role represents the use of a service provider playing a role in a particular collaboration to achieve some result. The type of the collaboration role specifies what responsibilities that service provider has to provide in order to play the role. The collaboration role type is often an Interface whose operations are the specifications for the role's responsibilities.

ClaimContainer is a business item class acting as a data provider. That is, the ClaimContainer is responsible for providing information required by the AdministerClaim contract. The data accessor functions of the ClaimContainer represent possible data transformations or derived data required by tasks in a business process. These are modeled as maps in WBM, but are viewed as simple operations on data item classes in UML2. The Claim Processor business actor is a role played by people in the business organization.
To determine the usage part of the contract, we need to know all the provided and required interfaces that participate in the collaboration. These are derived from the roles assigned as resources to tasks in the business process model. Examine the complete business process model to determine what tasks are assigned to each role in the resources model. Each role is viewed as an Interface, as shown in Figure 12 for the Claim Processor role resource. The responsibilities for this business worker are all the tasks for which this role is a resource (in other words, the tasks that are assigned to this role). If the task has more than one role resource, the first role resource is assumed to be responsible for the task. The other roles are considered to be participants in an unmodeled collaboration or incomplete contract. An Operation is added to the business worker interface for each task assigned to that role. The signature of the operation is derived from the task inputs and outputs.

The realization contract is shown as an Activity, which is the behavior of the Collaboration. The activity has the same name as the business process (and therefore the Collaboration), and is derived directly from the business process, as shown in Figure 13 for the Administer Claim process. Any implementation of this contract must be developed in such a way that its execution matches some possible path through this activity. The contract does not say how the implementation has to do this, only what it has to do.

The activity has an InputPin and OutputPin for each input and output of the business process. The names of these pins are the same as their names in the business process, while their types are the «BusinessEntity» classes derived from the business items in the process model. For example, the Administer Claim activity has an input claimContainer of type ClaimContainer, and an output claimContainer of the same type.
Each task in the business process model is either an invocation of a newly defined task, an invocation of a service provided by others, or the invocation of another process. The invocation of a task is represented by a CallOperationAction. The CallOperationAction has an additional target InputPin whose name is the name of the role resource assigned to the task in the process model, and whose type is the Interface corresponding to that role resource. The operation property of the CallOperationAction is the corresponding operation of the role interface. The CallOperationAction is also placed in an ActivityPartition whose name is the same as the role name assigned to the task, and whose Represents property is the role Interface. This helps show who is responsible for the action in the realization contract's activity. For example, the task Continue Claim Verification in the Administer Claim process becomes a CallOperationAction whose name is Continue Claim Verification. The action has input and output pins for each of its parameters, and an additional target input pin called claimProcessor of type ClaimProcessor, the role responsible for the task. The action is placed in an activity partition whose name is claimProcessor, and whose Represents property is the ClaimProcessor interface.
A process invocation in the process model is represented by a CallBehaviorAction. Such an action invokes the behavior of some other Collaboration. There is no additional target InputPin for a CallBehaviorAction because process invocations are not assigned to any role. These actions are therefore not assigned to any activity partition. CallBehaviorAction Validate Coverage is an example of a process invocation in the Administer Claim activity.
A task in a WBM model can also represent the invocation of some external service. A WBM service should be assigned a role resource. This role resource is then considered to be the party responsible for providing the service. Each WBM service corresponds to an Operation of an Interface whose name is the name of the role resource assigned to the service. This represents the interface provided by some service component that realizes this interface in the UML implementation model. A WBM service invocation then becomes a CallOperationAction in the realization contract activity, just like a task invocation. The target InputPin of this CallOperationAction is also derived from the role resource assigned to the WBM service representing the service provider. The Administer Claim activity contains one service invocation to Validate Credit.
The rest of the model elements in the realization contract activity are derived directly from corresponding model elements in the business process model. The details are provided in theBPM to BSM Mapping section.


Back to top
Each business process also has a corresponding «BusinessUseCase» use case. Typically these business use cases are used to represent the business requirements necessary to meet the business goals and objectives, and provide a link between the collaboration contract and the requirements in RequisitePro that it realizes. This use case could also be used to, for example, summarize the steps in the business process, or provide a place to list nonfunctional requirements for qualities of service implementations must meet. The use case documentation contains the description of the business process. A «BusinessActor» is used to show the participants in the business process. These are the role resources assigned to tasks in the business process. Each of these «BusinessActor» Actors realizes the corresponding «BusinessWorker» Interface to show the responsibilities of the actor.
You can also create diagrams that show the business use cases created for each business process, the actors that participate in the use case, the collaboration that specifies the business use case realization contract, and the roles that collaborate to specify the business function. For example, The AdministerClaim process results in the actors, use case, and realizing collaboration shown in Figure 14. To elaborate this business use case, attach a URL comment to the use case and use a word processor or some other means to fill in the use case details, such as RequisitePro. RequisitePro can associate use cases with documents, as well as to manage additional requirements and links between them.



Back to top
This section describes a high-level summary of the mapping between a business process model and the corresponding UML2 Business Services Model. Each mapping is described logically, with additional information as required to show how the mapping is manifest in the integration between WBM and RSM. In some instances, actual WBM or UML2 metaclasses are listed in the mappings. In other cases, Table 1 shows the mapping between concepts, as the metaclasses may obscure the meaning. Some business process model elements are viewed as many model elements in UML2 in order to specify the full contract.
Business Process Model to Business Services Model mapping BPM Element Mapping Details UML Element
Business Modeling Project
The top-level organizational structure for the WBM is a Business Modeling Project containing a file, resources.XMI, which provides a container for managing all the elements of the model described below. This is the same project in RSM, and corresponds to the business contract model. The business contract model is an RSM model with the RUP Business Modeling profile applied.
RSA can directly open the project resource corresponding to the root container business process model. Opening the resources.XMI file using RSA displays the WBM business process model as a Business Services Model expressing the contract between the business requirements and any implementation realizing those contracts. The Business Services Model is stereotyped as a Business Use Case Model and Business Analysis Model to indicate that it specifies the contract for meeting the business requirements.

The same project, and the UML2 Business Services Model when opening resources.XMI.
InformationModel, ProcessModel, OrganizationModel, ServicesModel, or Category
WBM catalogs are typed and contain only specific model elements. The UML2 packages corresponding to the WBM catalogs do not share this restriction, but the organizational structure of the UML model is the same as the WBM model. Many of these packages are not shown in the WBM project explorer, but are there none the less and are shown in the BSM.
Package

Process
The RUP approach to business modeling clearly separates the "black box", or external, and "white box", or internal, view of processes. The external view is provided by a Use Case where the internal view is provided by one or more realizations of the Use Case.
The BSM is a refinement of RUP that formalizes the relationship between requirements, analysis, and design elaboration steps. In the BSM, the Business Use Case represents some business goals and objectives. These requirements are then realized by a contract corresponding to the business process that specifies what implementations have to do, but not how they have to do it. That is, the BSM formally separates the specification (specification, contract or black box) from the realization (implementation, contract realization or white box) views of the business requirements and their possible realizations in IT systems.
The BSM model views the process as a contract describing the participating roles, their responsibilities, and the orchestration of their interaction necessary to meet the business requirements. The process is viewed as both a RUP Business Use Case Realization (a Collaboration) that realizes the business use case, and an activity. This collaboration specifies the contract implementers must realize, including both the usage contract (through provided and required interfaces) and the realization contract (through an Activity specifying the behavior of the collaboration). This Activity specifies the protocol for how the participating roles must interact when fulfilling their responsibilities in order to satisfy the contract. The activity is directly derived from the process as described below.

Business Use Case
and
Business Use Case Realization
Contract

Realization Contract

Role
Tasks in a process may be assigned to roles that are responsible for performing the tasks. Since the business process model is about the business, not automated systems supporting the business, the WBM model expresses both the external and internal views of a process. Therefore, it does not distinguish external and internal Roles, as is done in UML Business Modeling using the RUP methodology.
Each Role in the business process model that performs some task or provides some view represents a «BusinessActor» and a Interface used to define the responsibilities of the roles participating in the collaboration. Each task performed by a role (in any process) is mapped to an operation on the role's interface. The names of the Actor and Interface are derived directly from the name of the Role.
The role is also viewed as an ActivityPartition in the Activity attached as a behavior to the Collaboration. All CallOperationActions representing the invocation of tasks assigned to this role are placed in the corresponding ActivityPartition. The name of the partition is the same as the role name in the process model. The Represents property of the ActivityPartition is set to the Interface corresponding to the role type.

BusinessActor

Role Responsibilities

Resource Type
and
Resource
A Resource usually represents something either required to complete the Task or perhaps consumed during the Task. Individual and Bulk Resource type definitions in the process model are represented as Classes in the BSM, while specific resources are represented by instances of those classes (InstanceSpecification).

Class
and
InstanceSpecification

Repository
A repository in a process model represents a store of Business Items, items that can be shared between processes and tasks. A DataStoreNode in an Activity is used to model the same concept in UML. A UML2 DataStoreNode is a TypedElement visible within the containing Activity. It therefore cannot directly represent a global, reusable repository reference. For the BCM, a WBM global Repository is mapped to an InstanceSpecification and the DataStoreNode has a dependency whose target is that InstanceSpecification. An issue has been raised with the OMG UML2 RTF to address this problem.

DataStoreNode
and
InstanceSpecification

TaskInvocation

Global Task Invocation
The Task represents some unit of work performed in the process that is not further modeled. Processes are sequences of connected tasks performed by a Role (Roles) and may include produced and consumed Resources.
Each task assigned to a role represents a responsibility of that role to perform the task. These responsibilities are collected into and viewed as operations of the role interface corresponding to a role.
A task invocation in a process is represented by a CallOperationAction in an Activity that invokes the corresponding operation of the interface derived from the role responsible for performing the task.
The name of the operation on the role interface is directly derived from the name of the Task. For example, the Offer Reservation task is a responsibility of the Customer Service System interface and is invoked using a CallOperationAction in the Activity representing the realization contract.
A role also results in an additional InputPin added as the target for each CallOperationAction invoking a task assigned to that role. This InputPin is used to provide the role instance performing the task.

Role Interface

CallOperationAction

Process Invocation
The invocation of another process is represented as a CallBehaviorAction that invokes the Activity representing the invoked process. Processes are not assigned to roles and therefore do not have an additional target input pin.

CallBehaviorAction

Service Invocation
The invocation of a service is similar to the invocation of a task. The role resource assigned to a service is considered to be the provider of the service. An InputPin is added as the target of CallOperationAction for this role.

CallOperationAction

Connection
A connection between tasks and process invocations represent control and data flows that provide the sequencing of actions in a process in order to specify rules for how the roles performing tasks interact. These flows are viewed in the BSM as ControlFlows or DataFlows connecting the Actions in the Activity in order to express the same processing rules.

ControlFlow
or
ObjectFlow

Business Item(s)
Business Items in the WBM model represent information elements that flow between Tasks in a Process. Such information elements can be physical artifacts (such as reports or forms), electronic artifacts (such as e-mail or electronic document), or physical goods. These business items are represented as classes in the BSM. A business entity in the WBM business process model may or may not correspond to some persistent class in the UML business domain model. Usually these business entities correspond to data transfer objects that define data or messages exchanged between tasks and processes in the model. These data transfer objects are often views on the domain model, as specified in the analysis models that realize the contracts.

Business Item Class

Notification
notification is a (typically asynchronous) communication denoting some event occurrence in a process, or a change in state of some business item. A notification is viewed as a «BusinessEvent» in the BSM.

Business Event

Start/Stop
These nodes indicate the initiation and termination of processes in both the business process model and the BSM activity representing the realization contract.

InitialNode/
ActivityFinalNode

Decision/Merge
Decision and merged nodes in the business process model have similar representation in the BSM activity.

DecisionNode/MergeNode

Fork/Join
A process model can contain fork nodes representing the initiation of parallel activity execution, and join nodes that represent the synchronization points of these parallel activities. These have similar representations in the BSM activity.

ForkNode/JoinNode

Loop
The WBM model provides three looping constructs, a While, a Do, and a For loop. These are all viewed as a LoopNode in the BSM activity. (LoopNode is not currently supported by RSM).
LoopNode

Notification Broadcaster
When broadcasting a notification, the WBM model has a Notification Broadcaster model element that denotes the notification that it is sending. The BSM activity model views these notifications as a BroadcastSignalAction. (BroadcastSignalAction is not currently supported by RSM).
BroadcastSignalAction

Location
Locations and Location Definitions are used in the WBM models to denote geographic locations as a part of the organizational model. Each location definition in the process model is viewed as a class in the BSM. Each location, an instance of a location definition, is viewed as an InstanceSpecification of the class corresponding to the location definition.
Class/InstanceSpecification
Rule
In the WBM model, Rules can be attached to a number of elements, though primarily used in the Business Item catalog to define integrity rules for data definition. These rules are viewed as «BusinessRule» Constraints in the BSM.

Business Rule


Back to top
Integrating business process modeling and object modeling can greatly facilitate the translation of business concepts into deployed applications. Characteristics of such an integration should:
Make it easy to validate against requirements early and often in the development life-cycle Maximize communication fidelity and feedback during the development process Ensure systems can meet changing business requirements so they are not obsolete before they are deployed Help developers easily determine the effects of -- and track -- changes Engage the key business stakeholders who have the most business knowledge and are responsible for delivering business value
Contract-based development allows business analysts and developers to use the best aspects of both business process modeling and object modeling to capture business requirements and transform them into high-performance, maintainable object and service-oriented implementations.
Learn
RUP Plug-In for WBI Modeler: Extends UML2 to capture the Business Contract Model.
Business Driven Development: Represents an approach to developing business applications that focuses on establishing a clear understanding of the business goals and objectives that are to be achieved, and the roles, activities, and work products involved in analyzing processes, services, and deployed applications necessary to achieve them. BDD rounds out the solution by monitoring applications to collect data on key performance indicators to verify that IT solutions meet their intended business goals and objectives, and to provide a concrete foundation for evolving the business to reduce costs and provide increased value.
WebSphere Business Modeler: Enables business analysts to easily create, simulate, and vary business process models to ensure business goals and objectives are met.
IBM Rational Software Architect product page: Find technical documentation, how-to articles, education, downloads, and product information about Rational Software Architect.
Get products and technologies
IBM Rational Software Architect: Download a trial version from developerWorks. Provides the tools needed to view the Business Contract Model and develop service realization models that can be used to generate implementation code for different architectural styles.
Discuss
Participate in the discussion forum.
Rational Software Architect, Software Modeler, Application Developer and Web Developer forum: Ask questions about Rational Software Architect.



Jim Amsden has over 20 years of experience in designing and developing applications and tools for the software development industry. He holds a Masters in Computer Science from Boston University. His interests include contract-based development, agent programming, business-driven development, J2EE UML, and service-oriented architectures. He is co-author of "Enterprise Java Programming with IBM WebSphere". His current focus is on finding ways to integrate tools to better support agile development processes.

Please take a moment to complete this form to help us better serve you.

Did the information help you to achieve your goal?

Yes No Don't know


Please provide us with comments to help improve this page:



How useful is the information?

1 2 3 4 5
Not
usefulExtremely
useful




Share this....
Digg this storydel.icio.usSlashdot it!

Back to top

E-mail this page
Print this page
Digg this
Save to del.icio.us
About IBM
Privacy
Contact
Terms of use
IBM Feeds