business process modeling and simulation with uml

8/14/2019 Business Process Modeling and Simulation With UML

1/9

Business Process Modelingand Simulation with UML

Part II: Executing a UML Transaction Model with Rational Rose

by Pan-Wei Ng

Software Engineering SpecialistRational Software Singapore

Business modeling is an important activity insoftware development, and the Rational Unified

Process(RUP) provides a systematic approachto visually representing a business mode. It doesnot, however, provide a way to derive simulationmodels that support quantitative comparisonsbetween various improvement options. Lastmonth, in Part Iof this series, we defined a Unified

Modeling Language (UML) profile for a transactionmodel to fill this gap, showing how to map it from

business models in the RUP. Now, in Part II, wewill see how to execute the transaction model in a

simulation, using the Rational RoseProcessSimulator Add-In.

Setting Up a Simulation Engine

In Part Iof this series, we walked through the process of fully describing a

UML transaction model for a business use case: Visit Doctor. Once thatspecification process is complete, the model is ready for execution in a

simulation. This requires a simulation engine with internal operations asfollows (see Figure 1).

The simulator manages both element instances (i.e., generator andserver instances) and transaction instances (where transaction flowsare defined). Both are generalized as target instances.

Each element instance has a "Pending" request queue and an "InProgress" request queue.

Both transaction and element instances can schedule events, which aremanaged in chronological order by the simulator in an event queue.

pyright Rational Software 2002 http://www.therationaledge.com/content/may_02/t_businessModeling


2/9

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

Figure 1: Simulation Engine

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

Figure 2: Simulation Step

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


3/9

events produced in Table 1. Column one represents the event number, columntwo the simulation clock time (time elapsed since the simulation started), andcolumn three the event description. The last six columns represent thenumber of patients either queuing for (Q) or receiving service (S) from each ofthe 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, whichinitiate their transaction flows (see event 4). Since the inter-arrival rate is 15minutes, the first patient, Patient-0, is scheduled for a visit at time = 15minutes (see event 5).

Based on the transaction-flow definition, the first step requires Patient-0 to goto the Nurse and begin to queue up (see event 6). Now the queue length = 1


4/9

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

Analyzing Options

In practice, business process analysts and owners are not interested in theoutcome of single transactional flows. Rather, they are interested in multipletransactional flows, the utilization of resources, turnaround times, and so on.In addition, business processes are stochastic (subject to random variablesand guesswork) rather than deterministic (an inevitable consequence ofpreceding actions) by nature. This implies that arrival rates and service timesfollow different statistical distributions. Consequently, the simulation enginemust be capable of:

Generating multiple transactions.

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

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

Figure 3: Environment Model for UML Transaction Model Simulation


5/9

Now that the simulation engine has the desired capabilities, we can analyzethe outpatient hospital under various conditions. Figure 4 shows the queuelength for the nurses, doctors, and dispensary when patients arrive at auniform rate of between five and fifteen minutes (i.e., an average of every tenminutes). We can see that the queue for nurses and dispensary never exceedsone, but the queue for doctors exceeds one at times and may hit three oncertain 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 itrepresents the number of patients waiting. The utilization is plotted in Figure5. Recall that there are three nurses, two doctors, and one person in thedispensary. 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 stepsin the Visit Doctor transaction flow involves the retrieval of patient records.Suppose that an overenthusiastic IT consultant proposed the automation ofmanual records. This might result in more accurate records and so-called"customer satisfaction," but it would provide very little business value fromthe performance viewpoint, since the bottleneck is with the doctors, as isevident in the queue length in Figure 4 and the utilization numbers in Figure5.

To further illustrate this point, let's consider a case in which the patient arrival


6/9

rate is uniformly distributed between three and eight minutes. The resultingqueue lengths are depicted in Figure 6. The queue length increases withoutbounds, and in practice, patients will start to leave when they see such a longqueue. This problem can be resolved by hiring another doctor, or by lookingfor ways to reduce either the current diagnosis time of fifteen minutes, or thecurrent 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 themarket, most of them lack "use-case-driven" support; they are simply notdesigned for it. Even Rational Rose RealTime is not suitable for this applicationbecause an effective simulation tool must simulate in compressed time, asopposed to real time, so that one can compare many options in a relativelyshort period of time.

One good solution is to use Rational Rose as the base software, along with aRose Add-In. The benefits of doing this are many. First, Rose supports a use-case-driven-model approach; second, it already has strong features foreffectively manipulating model elements -- which significantly simplifies theimplementation effort. The use-case-model survey of the Process SimulatorRose Add-In is depicted in Figure 7.

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


7/9

The use cases are:

Describe Transaction Model.This use case allows the businessprocess analyst to describe the transaction model. The transactionmodel 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 businessprocess analyst to simulate the transaction model.

Analyze Simulation Results.This use case allows the businessprocess stakeholder to analyze simulation results such as the queuelengths at various time instances, and to compare results for differentsimulation parameters.

Figure 8: Transaction Model Meta-Model

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

A Unified Approach

This two-part series has focused on how to derive a transaction model fromthe RUP business models, but this approach is generic enough to derivetransaction models from use-case and analysis models, or design models, andsimulation is not limited to business processes. The same approach can beuseful in simulating computing resources; it is similar to the approach used in

RationalQualityArchitect(RQA) and Virtual User (VU) testing through

RationalRobot.

In RQA scenario testing, instead of sending messages to server stereotypes inthe transaction model, messages are sent to EJBs; in VU, testing messagesare sent to Web servers, application servers, and database servers. All are


8/9

based on the same fundamental concept of simulating transactions on someprocessing element. The key difference for business modeling is that not onlythe transactions, but also the resources, are simulated.This is NOT the casefor RQA or Virtual Testing, which both require some form of implementationcode.

Another important difference is that simulation can execute in compressedtime. In Section 0, each simulation run of four hours takes about five secondsto complete. This means that you can experiment with a lot more options in a

significantly shorter time than if you use actual real-time computingresources. Consequently, it is useful if mappings to the transaction model areavailable for the analysis model, process model, deployment model, and soon. This is not too difficult to accomplish, because these models are derivedusing a use-case-driven approach in the RUP. Taking the example of theanalysis 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 exploredifferent coupling patterns. This must be conducted at a high level ofabstraction; otherwise, the level of detail will be too overwhelming.

Another possible use of the transaction model from a business-modelingviewpoint is the derivation of supplementary specifications, particularly thosethat deal with numerical quantities such as performance and reliability, asillustrated in Figure 10.

Figure 10: Requirements Traceability from Business and Transaction Models

Mapping behavioral requirements from business models to the use-case


9/9

models has been dealt with in the RUP, which has a standard algorithm forthis purpose. However, the quantification of nonbehavioral requirements ismore difficult. The specification and execution of the transaction model caninclude a justification of a requirement that says, "All records must beprocessed in eight seconds" in light of business needs. The use-case-drivenapproach inherent in the transaction model makes this translation even moreapparent.

Conclusion

In this series, we have shown how to achieve business process simulation witha UML, use-case-driven approach and demonstrated how simulation cansupport the software engineering process.

There are many ways in which this work can be continued. The profile of thetransaction model needs further refinement to include different transactionalpatterns, such as breakdown and repair of servers. The simulation engine canbe refined to handle different transaction input distributions. The futuredirection of this approach will depend on the willingness of practitioners toadopt it and experiment with it.

Fo r m o r e i n f o r m a t i o n o n t h e p r o d u c t s o r s e r v i ce s d is cu s s e d in t h i s

a r t i c l e , p l e a s e c l i c k h e r e a n d f o l l o w t h e i n s t r u c t i o n s p r o v id e d . Th a n k

y o u !

Copyright Rational Software2002 | Privacy/Legal Information

business process modeling and simulation with uml

Documents