Copyright Rational Software 2002

http://www.therationaledge.com/content/may_02/t_businessModeling_pn.jsp

Business Process Modeling and Simulation with UML

Part II: Executing a UML Transaction Model with Rational Rose
by Pan-Wei Ng Software Engineering Specialist Rational Software Singapore Business modeling is an important activity in software development, and the Rational Unified Process (RUP) provides a systematic approach to visually representing a business mode. It does not, however, provide a way to derive simulation models that support quantitative comparisons between various improvement options. Last month, in Part I of this series, we defined a Unified Modeling Language (UML) profile for a transaction model to fill this gap, showing how to map it from business models in the RUP. Now, in Part II, we will see how to execute the transaction model in a simulation, using the Rational Rose Process Simulator Add-In.

Setting Up a Simulation Engine

In Part I of this series, we walked through the process of fully describing a UML transaction model for a business use case: Visit Doctor. Once that specification process is complete, the model is ready for execution in a simulation. This requires a simulation engine with internal operations as follows (see Figure 1).
G

The simulator manages both element instances (i.e., generator and server instances) and transaction instances (where transaction flows are defined). Both are generalized as target instances. Each element instance has a "Pending" request queue and an "In Progress" request queue. Both transaction and element instances can schedule events, which are managed in chronological order by the simulator in an event queue.

Transaction instances process events according to the transaction flow. Element instances process events in accordance with resource availability. In other words, if a resource is available, then it can handle requests in its queue.

Figure 1: Simulation Engine

At each simulation step (see Figure 2), the simulator removes the first event from the event queue and advances its clock to the event time. The simulator then delegates processing to the target instance, which can be either a transaction instance or an element instance. The target instance will then call the appropriate handler based on the event name.

Figure 2: Simulation Step

We will walk through the events generated to understand how the simulation engine operates. For the sake of simplicity, we will look at the generation for only one transaction flow instance and summarize the complete sequence of

events produced in Table 1. Column one represents the event number, column two the simulation clock time (time elapsed since the simulation started), and column three the event description. The last six columns represent the number of patients either queuing for (Q) or receiving service (S) from each of the servers (Nurse, Doctor, or Dispensary).
Table 1: Execution of Events for UML Transaction Model Simulation

The simulation begins with the simulator starting the server instances at time = 0 minutes (see events 1-3). The simulator also starts the generators, which initiate their transaction flows (see event 4). Since the inter-arrival rate is 15 minutes, the first patient, Patient-0, is scheduled for a visit at time = 15 minutes (see event 5). Based on the transaction-flow definition, the first step requires Patient-0 to go to the Nurse and begin to queue up (see event 6). Now the queue length = 1

for the Nurse. Since there are no other patients, the Nurse is available to retrieve the patient record, which takes 1 minute. This completes at time = 16 minutes (see event 7). Patient-0 continues the transaction flow. The rest of the execution details are available in Table 1, which is completely generated by a prototype Rational Rose Add-In called Process Simulator, which is discussed below.

Analyzing Options
In practice, business process analysts and owners are not interested in the outcome of single transactional flows. Rather, they are interested in multiple transactional flows, the utilization of resources, turnaround times, and so on. In addition, business processes are stochastic (subject to random variables and guesswork) rather than deterministic (an inevitable consequence of preceding actions) by nature. This implies that arrival rates and service times follow different statistical distributions. Consequently, the simulation engine must be capable of:
G

Generating multiple transactions. Generating different statistical distributions. Monitoring quantities over the simulation execution.

The first two capabilities require the simulation engine to execute the transaction model under different environments. This can be achieved by modifying model element parameters individually. Alternatively, it is possible to collectively manage the parameters of interest by placing their values within an environment. An environment model will then manage different environments, and execution results will be associated with each environment. This is summarized in Figure 3.

Figure 3: Environment Model for UML Transaction Model Simulation

Now that the simulation engine has the desired capabilities, we can analyze the outpatient hospital under various conditions. Figure 4 shows the queue length for the nurses, doctors, and dispensary when patients arrive at a uniform rate of between five and fifteen minutes (i.e., an average of every ten minutes). We can see that the queue for nurses and dispensary never exceeds one, but the queue for doctors exceeds one at times and may hit three on certain occasions.

Figure 4: Queue Lengths for Uniform Arrival Rate of Every Five to Fifteen Minutes

Note that the queue length is not the same as utilization, because it represents the number of patients waiting. The utilization is plotted in Figure 5. Recall that there are three nurses, two doctors, and one person in the dispensary. We can see that utilization for the nurses is never more than one, and utilization for the doctors hits two most of the time.

Figure 5: Utilization for Uniform Arrival Rate of Every Five to Fifteen Minutes

What does this mean for business improvement? Recall that one of the steps in the Visit Doctor transaction flow involves the retrieval of patient records. Suppose that an overenthusiastic IT consultant proposed the automation of manual records. This might result in more accurate records and so-called "customer satisfaction," but it would provide very little business value from the performance viewpoint, since the bottleneck is with the doctors, as is evident in the queue length in Figure 4 and the utilization numbers in Figure 5. To further illustrate this point, let's consider a case in which the patient arrival

rate is uniformly distributed between three and eight minutes. The resulting queue lengths are depicted in Figure 6. The queue length increases without bounds, and in practice, patients will start to leave when they see such a long queue. This problem can be resolved by hiring another doctor, or by looking for ways to reduce either the current diagnosis time of fifteen minutes, or the current prescription time of three minutes.

Figure 6: Queue Lengths for Uniform Arrival Rate of Every Three to Eight Minutes

Automating Model Execution

Although there are a number of sophisticated process-simulation tools on the market, most of them lack "use-case-driven" support; they are simply not designed for it. Even Rational Rose RealTime is not suitable for this application because an effective simulation tool must simulate in compressed time, as opposed to real time, so that one can compare many options in a relatively short period of time. One good solution is to use Rational Rose as the base software, along with a Rose Add-In. The benefits of doing this are many. First, Rose supports a usecase-driven-model approach; second, it already has strong features for effectively manipulating model elements -- which significantly simplifies the implementation effort. The use-case-model survey of the Process Simulator Rose Add-In is depicted in Figure 7.

Figure 7: Rose Process Simulator Add-In Use-Case Model Survey

The use cases are:

G

Describe Transaction Model. This use case allows the business process analyst to describe the transaction model. The transaction model is an extension of the Rose model, with appropriate extensions, annotations, and organization following the UML profile in Figure 8. Simulate Transaction Model. This use case allows the business process analyst to simulate the transaction model. Analyze Simulation Results. This use case allows the business process stakeholder to analyze simulation results such as the queue lengths at various time instances, and to compare results for different simulation parameters.

Figure 8: Transaction Model Meta-Model

An architectural prototype of the Process Simulator Add-In has been developed and used to generate the execution results described earlier, in Table 1 and in Figures 4, 5, and 6.

A Unified Approach
This two-part series has focused on how to derive a transaction model from the RUP business models, but this approach is generic enough to derive transaction models from use-case and analysis models, or design models, and simulation is not limited to business processes. The same approach can be useful in simulating computing resources; it is similar to the approach used in Rational QualityArchitect (RQA) and Virtual User (VU) testing through Rational Robot. In RQA scenario testing, instead of sending messages to server stereotypes in the transaction model, messages are sent to EJBs; in VU, testing messages are sent to Web servers, application servers, and database servers. All are

based on the same fundamental concept of simulating transactions on some processing element. The key difference for business modeling is that not only the transactions, but also the resources, are simulated. This is NOT the case for RQA or Virtual Testing, which both require some form of implementation code. Another important difference is that simulation can execute in compressed time. In Section 0, each simulation run of four hours takes about five seconds to complete. This means that you can experiment with a lot more options in a significantly shorter time than if you use actual real-time computing resources. Consequently, it is useful if mappings to the transaction model are available for the analysis model, process model, deployment model, and so on. This is not too difficult to accomplish, because these models are derived using a use-case-driven approach in the RUP. Taking the example of the analysis model, the mapping depicted in Figure 9 can be used.

Figure 9: Analysis Model to Transaction Model Mapping

Since the analysis model can now be simulated, the architect can explore different coupling patterns. This must be conducted at a high level of abstraction; otherwise, the level of detail will be too overwhelming. Another possible use of the transaction model from a business-modeling viewpoint is the derivation of supplementary specifications, particularly those that deal with numerical quantities such as performance and reliability, as illustrated in Figure 10.

Figure 10: Requirements Traceability from Business and Transaction Models

Mapping behavioral requirements from business models to the use-case

models has been dealt with in the RUP, which has a standard algorithm for this purpose. However, the quantification of nonbehavioral requirements is more difficult. The specification and execution of the transaction model can include a justification of a requirement that says, "All records must be processed in eight seconds" in light of business needs. The use-case-driven approach inherent in the transaction model makes this translation even more apparent.

Conclusion
In this series, we have shown how to achieve business process simulation with a UML, use-case-driven approach and demonstrated how simulation can support the software engineering process. There are many ways in which this work can be continued. The profile of the transaction model needs further refinement to include different transactional patterns, such as breakdown and repair of servers. The simulation engine can be refined to handle different transaction input distributions. The future direction of this approach will depend on the willingness of practitioners to adopt it and experiment with it.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information