Derivation of Petri Net Performance Models from UML Speci cations of Communications Software Peter King and Rob Pooley Department of Computing and Electrical Engineering Heriot-Watt University Edinburgh EH14 4AS pjbk or
[email protected] Abstract
As hardware becomes faster and bandwidth greater, the determination of the performance of software based systems during design, known as Software Performance Engineering (SPE), is a growing concern. A recent seminar of experts at Dagstuhl and the First International Workshop on Software and Performance have both highlighted the need to bring performance evaluation into the software design process. The Uni ed Modelling Language (UML) has emerged in the last two years as a widely accepted standard notation for software design and it is an attractive vehicle for SPE. In this paper UML's Collaboration and Statechart diagrams are shown to allow systematic generation of Generalised Stochastic Petri Net (GSPN) models, which can be solved to nd their throughput and other performance measures. Using the example of communication via the alternating bit protocol, such a mapping is demonstrated and the resulting GSPN solved using the SPNP package. The basis of a usable methodology for SPE is demonstrated.
Keywords: software performance engineering, Uni ed Modelling Language, stochastic Petri nets, communications protocols
1 Introduction The hardware in computers and communication networks is becoming faster and its o ered bandwidth continues to increase. As a result the software is increasingly seen as the bottleneck in such systems. It is widely accepted that at least eighty percent of the performance of a system is determined by its general architecture and that this is as true of software as it is of hardware. This makes it essential that performance can be analysed from the earliest stages in a design. To encourage designers to incorporate performance analysis, work such as that by Smith on Software Performance Engineering[23] and by Beilner and others on HIT[3] has built new performance evaluation frameworks aimed at designers. At the same time others have added performance annotations to existing design notations[22, 25, 2, 9, 15, 8] and provided routes for analyzing the resulting models. Most success is likely to come from this second approach. The integration of performance estimation with the system design process is the goal of the work described in this paper. In the last two years, the software design community has embraced a move towards a new design notation, intended to provide a common vocabulary for software based systems. This Uni ed Modelling Language (UML)[18, 21, 5] is gaining widespread acceptance and this has made it possible to focus on a single notation. Since the notation includes both static and dynamic aspects of systems it is very well suited to generating performance results, although additional information on timings and branching probabilities is needed. Here we consider an example of using UML to generate Petri net models for performance prediction in a communication network. 1
The rest of this paper is structured as follows. Section 2 describes the application modelled { a simple network using the alternating bit protocol (ABP). Section 3 considers how to model this application in UML. Section 4 looks brie y at how UML models have been used in performance analysis to date. This includes examples of the use of UML with di erent solution approaches. Section 5 uses the UML model to generate a Generalised Stochastic Petri Net (GSPN)[16] model of the alternating bit protocol and its solution using SPNP[4]. Finally section 7 draws conclusions from this work and suggests the way forward in developing the approach.
2 The alternating bit protocol The alternating bit protocol (ABP)[1] is the simplest known protocol for reliable communication between two nodes. It uses ow control with a window size of one, which can be encoded as a single bit in any packet. A transmitter rst sends a packet with the sequence bit set to zero. It then waits until either it receives a corresponding ack packet from the receiver or until the de ned timeout period has been exceeded, when it assumes the packet is lost and retransmits. Once an ack is received the transmitter can send its next packet, with the bit set to one. It again awaits the corresponding ack, retransmitting after each timeout period. This continues, with the sequence bit alternating on successive packets. This protocol has been formally veri ed, for instance by Milner [17]. Its performance has been studied several times, including by the use of the TIPP stochastic process algebra [10].
3 Modelling ABP in the Uni ed Modelling Language The Uni ed Modelling Language (UML)[18] is a graphically based notation, which is being developed by the Object Management Group as a standard means of describing software oriented designs. It contains several di erent types of diagram, which allow di erent aspects and properties of a system design to be expressed. Diagrams must be supplemented by textual and other descriptions to produce complete models. For example, a use case is really the description of what lies inside the ovals of a use case diagram, rather than just the diagram itself. For a fuller account of UML see[21, 5]. More recently there has been interest in exploiting at least some parts of the UML for real time and embedded systems design and hardware design. These have focussed on the interaction and statechart views within the notation. We have found, similarly, that these views are most appropriate to the modelling of communications protocols, but we also believe that use case models are important when considering how such protocols will be used to meet user needs.
3.1 Use case models
In recent years the most radical addition to the rst generation of object oriented modelling approaches is use case modelling. This shows a system in terms of the external users of the system, known as actors and usually shown as \stick people". An actor may be a system, not necessarily a person. Each actor is shown as participating in one or more use cases, shown as ovals linked to the participating actors. A use case is some high level activity or capability of the system. Use case diagrams are signi cant in showing external systems and users that initiate functions. There is nothing inherently object oriented in use case models. What they provide is a bridge from user level requirements to implementation views. In particular, a use case translates into a number of scenarios, each expressing one sequence of actions when the corresponding activity is undertaken. Each scenario can be expressed as an interaction, involving the objects used to implement the system. 2
Transfer file
Telnet command
Client
Server
Browse Web page
Figure 1: Use case diagram for nodes communicating Figure 1 is an example of a use case diagram showing a communications network from the user perspective. Each use case represents one class of application which uses the underlying protocols to communicate. For simplicity we assume only point to point communication is required.
3.2 Static design diagrams
UML is an object oriented design formalism. Thus the core of the language is the class diagram, where the classes of object which form the building blocks of systems are described. These will be familiar to anyone who has used object oriented methods, with each class having a name { possibly accompanied by a stereotype and/or a set of properties for this class a set of attributes { representing internal data within objects a set of operations { representing methods or functions supported by objects of that class These may be shown in three compartments within the basic class rectangle. Only the name is compulsory and is either in the topmost compartment or the other compartments are omitted.
Class relationships
Important relationships between classes of objects are shown by associations, which indicate that these classes are linked by a particular aspect of the design; associations are very general; composition and aggregation are special forms of association, dependencies, which show that one class cannot function without something provided by another, re nements, a form of specialisation, where one thing is a more detailed version of another, generalisations, one class is a generalisation (super class), the other is a specialisation (sub class). 3
Active Process {abstract}
+receive(p:Packet,b:Bit)
Sender
Channel receives using
sends using 1
1
1
+ pSend(p:Packet)
Receiver
1
+ send(p: Packet, b: Bit)
+receive(p:Packet,b:Bit)
+receive(p:Packet,b:Bit) 2 communicates over
communicates with
1 Node
Figure 2: Class diagram for nodes communicating For the purposes of this paper, we assume that classes and objects exist as the fundamental units of description within a design. In particular, classes encapsulate behaviour, which can be described by a state machine description. In the ABP example we identify the classes shown in Figure 2.
Node is the basic component which handles communications to and from one point in the network.
It has a Sender and a Receiver, which are shown as permanent components within it, linked by a composition association, with a black triangle indicating the owning class. Channel is the logical communications medium. We show a node as communicating over two channels, one in each direction. Each channel is associated with one sender and one receiver. It supports the operation send. We do not give any further detail here. ActiveProcess is a generalisation of Sender and Receiver. It is given the property {abstract} since it cannot sensibly be instantiated itself. It requires all its subclasses to provide an operation receive, which is given in italics in the class diagram to indicate that it is not implemented at this level of generalisation. Its specialisations di er in the rest of their behaviour. They support di erent operations { pSend for Sender and forward for Receiver. These operations are explained when we consider interaction models below. Sender is the sending process in a node. It is shown as a specialisation of ActiveProcess. Receiver is the receiving process of a Node. It too is shown as a specialisation of ActiveProcess. 4
3.3 Interaction diagrams
UML de nes two forms of diagram to represent the way that messages are passed between objects in a system. These two forms of interaction diagram can be generated automatically from each other in the CASE tools which are available to support UML.
Sequence diagrams Sequence diagrams are based on message sequence charts[12]. Objects are
shown as boxes with dashed lines extending vertically below them. As these lines move down the page, they represent the passing of time. Arrows across the page show the sequences of messages passed between objects as time passes. Periods of activity by an object may be shown as a bar, called an activation, overlying its dashed life line. s:Sender
outChan:Channel
backChan:Channel
r:Receiver
user:Client
provider:Server
pSend(aPacket) send(aPacket,0) receive(aPacket,0) forward(aPacket) send(acq,0) receive(acq,0)
Figure 3: A sequence diagram showing a scenario in the ABP Each sequence diagram represents one or more routes through the unfolding of a use case (high level) or of an operation in a class (low level). If a single route is shown, one particular set of conditions is being assumed. Such a set of conditions is termed a scenario. Conditional behaviour, represented by placing a guard such as [r=invalid] on a message, can be used to show more than one possibility or even all possibilities, but this may be very complicated to represent. The example in Figure 3 shows a successful transmission with the sequence bit set to zero and no timeouts. The messages are all shown as half-arrows or hooks, since this represents asynchronous message passing. For synchronous behaviour full, solid arrows are used. Since behaviour is asynchronous, we do not use activations. Collaboration diagrams Here time is not represented explicitly. Instead the emphasis is on showing which objects communicate with which others. Messages are numbered to show the order in which they should happen. Nesting can be shown as a decimal numbering scheme. Partial orders, representing concurrency, can be shown by using names instead of numbers at the appropriate level. The example in Figure 4 shows the same scenario as the sequence in Figure 3.
3.4 State and activity diagrams
UML de nes state diagrams, which allow a class to be de ned in terms of the states it can be in and the events which cause it to move between states. They are essentially Harel statecharts[6]. These are fairly conventional state transition diagrams except for the following: 5
provider:Server
user:Client pSend(aPacket)
forward(aPacket) send(aPacket,0)
outChan:Channel
receive(aPacket,0)
s:Sender
r:Receiver
receive(acq,0)
backChan:Channel
send(acq,0)
Figure 4: The ABP modelled in a UML collaboration a state may indicate that the object is engaged in some activity; transitions between states can be due to messages or to changes in certain conditions or to a combination of these; states can be nested within super-states. The example in Figure 5 shows the internal behaviour of a Sender. This should correspond to the behaviour of all interactions involving instances of this class. The transitions shown are triggered either by incoming messages, such as the deliver(ack,1) message which triggers the transition from state Sent 1 to state Can Send 0, or by the passing of time, such as the after(t) indicating the timeout which triggers transitions from both Sent 0 and Sent 1 to themselves. The self transitions, where a transition is shown leaving a state and returning to itself, are used to show the actions which result at this point, as with the need to resend the packet after a timeout, or to indicate that certain messages can be accepted and are ignored, such as the arrival of a duplicate ack in the states Can Send 1 and Can Send 0.
3.5 Implementation diagrams
UML de nes two models which describe how your system is implemented.
The component model shows the dependencies between parts of the code, The deployment model shows the structure of the system at run-time: which parts run on which processors and how the hardware is con gured to provide necessary resources.
A component diagram can show dependencies of various sorts among such components. The dependency is shown by a dashed arrow between components. Stereotypes may be used to de ne the type of dependency. The component which the arrow leaves is said to depend on the component to which it goes.
6
receive(ack,1)
receive(ack,1) Sent 1
Can Send 0
pSend(p)/^out.send(p,0) after(t)/^out.send(p,1) after(t)/^out.send(p,0) pSend(p)/^out.send(p,1)
Can Send 1
receive(ack,0)
Sent 0
receive(ack,0)
Figure 5: A state diagram
Node
Figure 6: A component diagram showing runtime dependencies
Components at runtime In the example shown in Figure 6 there is an example of service
dependencies. In a program running on a single machine these are calling dependencies between functions. In distributed applications they might be remote procedure calls. Here they are packets being transmitted. Component diagrams do not show instances of components, merely the dependencies which apply between all components of one type and all components of another. Thus the component type Node depends on another instance of itself to be able to transmit and we show it only once with the dependency going back to Node.
De ning hardware A deployment diagram shows what runs where. It may simply show the
physical machines and devices, but that is only useful if you are building hardware systems without regard to what they will run. We start by considering the physical system, made up of processors, and devices such as disk controllers which provide services to other hardware elements. Unbroken lines between boxes represent physical connections between machines. (Strictly speaking these are associations, like 7
those in class diagrams.) These may represent cables, local area networks, modems and phone lines or whatever. A link can be given a name and a stereotype, so that it is clear both what sort of link (stereotype) we have and what is the name of a particular link. Further details may be given as properties within the speci cation of the link.
:HostComputer
:HostComputer
wire B
Figure 7: Just the hardware
Deploying components When we add the software components, we show how the system is to
operate at runtime. We can also show dynamic behaviour, where either data or code can migrate from machine to machine. Data may also be allowed to migrate between components on the same machine.
node2:Node
node1:Node
:HostComputer
:HostComputer
wire B
Figure 8: A deployment diagram with the software The example in Figure 8 shows two instances of Node deployed in the hardware from Figure 7. Since these are instances, they are shown underlined and with a name before their type. The dependency is replicated in both directions. The physical system must support communication between components which have a dependency between them.
4 Using UML for Performance Modelling In this section we survey existing ideas for exploiting UML designs for performance modelling. These now include both simulation methods and queueing network modelling approaches. We start by considering each form of description in turn. We then consider an approach combining di erent approaches. 8
4.1 Exploiting implementation diagrams
Implementation diagrams provide the nal mapping onto computing and storage devices. They are essential in de ning contention and quantifying resources which are available. One approach is to de ne a correspondence to an underlying queueing model. Components in such a model can be mapped onto servers. Links become queues with nite service rates. The overall system can then be modelled as an open queueing network. This approach was used by Pooley and King[20] to model a simple autoteller machine system.
4.2 Direct simulation of sequence diagrams
Several previous papers have identi ed sequence diagrams as having the potential to generate and display useful information relating to performance. As already noted, time is represented in sequence diagrams by distance downwards vertically. This is usually just an intuitive guide to timing issues, allowing orderings to be seen quickly in straightforward cases. There are, however, many designs, notably those involving iteration within sequential behaviour, where this breaks down. We have decided that sequence diagrams are, therefore, more suited to being a display format than to being a detailed behavioural speci cation format.
Software Performance Engineering using Sequence Diagrams
Smith and Williams have published a number of case studies [27, 24] where they show how an object oriented design can be modelled, starting from the class diagram and appropriate scenarios expressed as sequence diagrams. A mapping from sequence diagrams into Smith's SPE ED modelling language is used. This model is solved initially by path length analysis. As design proceeds and better information is obtained, the model is simulated to get more reliable estimates. For distributed object systems, where critical, fairly simple scenarios can often be found, this method is shown to be very useful. It is particularly helpful in early lifecycle analysis.
Sequence diagrams as traces
Timing information can be added by labelling messages with relative timing constraints, using nested numbering of messages to describe exact orderings. The result is still only really useful as a debugging aid in all but simple cases. In a prototype simulation tool Kabajunga and Pooley[13, 14] encoded the information about time intervals between messages, along with object names, in a driver le. This allowed for probabilistic timings, such as negative exponential inter-arrival time distributions. It was then used to drive a simple discrete event simulator, which generated an animated sequence diagram as a trace of events. Random timings allowed realistic performance prediction and testing of assumptions about the possible ordering of messages.
4.3 Simulation of collaborations
Essentially collaborations and sequences contain equivalent information. It is perhaps more natural, however, to build discrete event simulation models, especially those using a process oriented approach, from collaborations.
Automated simulation { Permabase
In a project sponsored by BT, a group at the University of Kent at Canterbury have built a system for modelling distributed object systems by automatically generating simulation models from UML use case and interaction models[26]. This work uses Rational Rose, a UML CASE tool, for input and SES workbench as its simulation engine. The use cases provide a workload model, in a similar way to the work described in this paper. The interactions de ne the behaviour of the 9
components in the system and, rather than using UML's deployment models, it de nes its own Composite Modelling Data Structure to build complete models.
Statecharts and collaborations
Pooley and Hargreaves[7] de ned and built a Java class library for simulation of combined statecharts and collaborations. This supported animation of the execution of such models, which looked similar to Figure 9. This was built on top of the Simjava simulation package[11].
5 Deriving a Petri net model of ABP The task of performance modelling requires insight and skill. This will always be true. We can, however, reduce the number of mechanical tasks needed in this process. In particular, we can de ne and implement mappings from UML designs into appropriate performance modelling formalisms. In this section we develop a detailed model using Petri nets, exploring the automatic mapping from combined collaboration and statechart models.
5.1 Petri nets
Petri nets are a formalism which has been developed to describe the concurrent behaviour of interacting systems. A system is represented graphically using places, transitions, arcs, and tokens. Places, graphically represented by circles, stand for the sub-states that parts of the system can be in. A token, indicated by a spot, is present whenever that part of the system is in the corresponding sub-state. The place is said to be marked. Transitions are represented by solid bars. Transitions have input arcs which link places to transitions, and output arcs which link transitions to places. There are no arcs directly from one place to another or from one transition to another. A transition is enabled if all of the places attached to its input arcs have a token present. A transition which is enabled may re, causing one token to be removed from each of its input places, and one token to be added to each of its output places. Traditional Petri nets are used to investigate such issues as mutual exclusion and freedom from deadlock. Deadlock occurs if the net can ever reach a state in which no transition can re. Mutual exclusion can be demonstrated by proving that two places in di erent components are never simultaneously occupied by a token. Peterson[19] is an excellent introductory text on Petri nets that shows how to use Petri nets for these problems. Traditional Petri nets do not measure time in any way. A number of extensions have added timing information, sometimes to allow more powerful theorems to be proved about the set of states that can be reached. The most popular timed extension is to specify stochastic Petri nets, in which some transitions re a randomly distributed time after they become enabled. These are usually represented by an open bar. If the distribution of time until an enabled transition res is exponential, then the set of states that the Petri net can enter forms a Markov process, and its transition matrix can be generated, and performance metrics can be calculated from the steady state solution.
5.2 Use case and workloads
The actors in use case diagrams should represent all external stimuli to the system being modelled. There is considerable disagreement about which external systems should be shown here, but at least all initiators of activities within the system should be represented. It seems logical, therefore, to use actors as the basis for de ning workloads in the system. Each actor does not correspond to a single person or system, but rather to a (set of) r^ole(s) played by one or more people or systems. Thus each actor may represent just one part of the workload for one part of a system. Similarly, each use case represents one class of requests. In the ABP model, we have shown three use cases, which might well represent di erent packet length and arrival rate distributions. 10
5.3 A UML combined state and collaboration model
The diagram in Figure 9 shows the collaboration from our UML model of ABP, with the statecharts of all the objects embedded within them. If this is a correct model, all possible behaviours of the model are captured. Each object can be in any of the states within its statechart. The current state of the whole system is represented by the combination of the states of the individual objects. The number of possible combinations may be greater than the number of combinations which the system can actually evolve into. This will depend on the initial combination of states and the behaviours of the objects. The scenarios which the system can execute should correspond to the overall behaviour of this model and the resulting states form the reachable subset of overall states. receive(ack,1)
receive(ack,1)
back : Channel
Can Send 0
Sent 1
Idle pSend(p)/^out.send(p,0) s:Sender
after(t)/^out.send(p,1)
send(n)
after(t)/^out.send(p,0)
^s.receive(p,n) [prob(p)]
pSend(p)/^out.send(p,1)
receive(ack,0)
Can Send 1
after(d)
Sent 0
Sent n
Succeed or Fail
[prob(1-p)]
Arrived
receive(ack,0)
out : Channel receive(p,0)/^back.send(ack,0)/^n.forward(p)
Idle
receive(p,0)/^back.send(ack,0) send(p,n)
^r.receive(p,n) [prob(p)] Wait for 0
Wait for 1 after(d) Sent n
Succeed or Fail
[prob(1-p)]
receive(p,1)/^back.send(ack,1)
Arrived
receive(p,1)/^back.send(ack,1)/^n.forward(p) r : Receiver
Figure 9: The alternating bit protocol modelled as a UML collaboration with embedded statecharts
5.4 The corresponding GSPN model
Translation of the state diagram representing each object into a corresponding stochastic Petri net is straightforward. Each state in the state diagram is represented by a place in the Petri net. A token is present in a place if the state machine is in the corresponding state. The transitions in the state machine are also mapped into transitions in the Petri net. These Petri net transitions all have one input and one output place, corresponding to the states of the state machine. A single transition in the state machine may be represented by several di erent transitions in the Petri net, 11
but the Petri net transitions all have the same input and output place. In Petri net terminology they are competing transitions. In isolation, which transition res is unimportant. Consider the sender process in the alternating bit protocol; it has four states, two corresponding to sequence number 0 for the packet and two corresponding to sequence number 1. It cycles between CanSend0, Sent0, CanSend1, and Sent1, in that order. It moves from CanSendi to Senti when a new packet becomes available, and is transmitted on the forwards channel. Likewise, when the acknowledgment of packet i arrives, the state of the sender process changes from Senti to CanSendi + 1. When the sender is in state Senti it periodically times out and sends a further copy of the packet with sequence number i. This transition is a self loop and does not change the state of the process. The after(t) labelling on the transition in the state diagram is captured by using a timed transition in the Petri net. The Petri net corresponding to this state diagram is shown in Figure 10. CanSend0 InitSend0 TimeOut0
Sent0 ReceiveAck0
CanSend1 InitSend1 TimeOut1
Sent1 ReceiveAck1
Figure 10: Petri net corresponding to Sender Likewise, the Petri net corresponding to the state diagram for the Receiver process is a direct translation which can be seen in Figure 11. The channel will deliver packets. When the receiver is in state Waitfor0, a packet with sequence number 1 will cause a transition to the same state, a self loop. When sequence number 0 arrives, the receiver moves to state Waitfor1, and subsequent receptions of sequence number 0 cause transitions which do not change state. Each transition also causes the transmission of an acknowledgment with the same sequence number as the packet. The channels are modelled using a Petri net shown in Figure 12, one net for each direction of transmission. The channel is initially idle, and makes the transition to Sent when a packet is transmitted. A timed transition corresponds to the after(d) guard on the transition to Succeed or Fail state, where probabilities are attached to the transitions OK and Loss to represent the probability of transmission error. If an error occurred, the Loss transition occurs and the channel 12
Duplicate0
Waitfor0 Receive0 Duplicate1
Waitfor1 Receive1
Figure 11: Petri net corresponding to Receiver becomes idle again. If no error occurs, then the channel enters the Arrived state, until the packet can be delivered, when it reverts to the idle state again. The Petri net shown for the channel is a slight simpli cation, since separate Sent, SucceedorFail and Arrived places are needed to represent the two possibilities for sequence numbers. Accept
Idle
Deliver
Loss Transmit
Sent
OK
SucceedOrFail
Arrived
Figure 12: Petri net corresponding to Channel It is noticeable that each Petri net has a straightforward invariant: the number of marked places is always identically 1. This phenomenon occurs because there is no concurrency within the UML objects. With this observation, we can combine the Petri nets corresponding to the various state diagrams by identifying transitions in the separate Petri nets with one another. In particular, the Accept transition of the forward channel is identi ed with the InitSendi and TimeOuti transitions in Sender. The Idle place in the channel becomes an input place to those transitions, and the Sendi 13
place becomes an output place. Likewise, the Deliver transition in the channel is identi ed with the Receivei and Duplicatei transitions in the Receiver. For the reverse channel, which carries the acknowledgments, the Accept transition in the Petri net is identi ed with Receivei and Duplicatei transitions in Receiver. Figure 13 shows the part of the complete Petri net model corresponding to the transmission and reception of packets with sequence number 0. The arcs and places relating to the reverse channel carrying acknowledgments and for the forward channel carrying packet with sequence number 1 are not shown. Note that the Idle place for the forward channel is not duplicated, only the places corresponding to the presence of a packet. Idle CanSend0 Duplicate1 Loss
Waitfor0
InitSend0 Transmit
Sent0
Sent
OK
SucceedOrFail
Arrived
Receive0
TimeOut0
Waitfor1
ReceiveAck0 Duplicate0 Receive1
CanSend1
Figure 13: Complete Petri net
6 Numerical Results In order to con rm the correctness of the model that we have constructed, we have compared our numerical results with those calculated by Hermanns et al.[10] using their TIPP system. This is a stochastic process algebra which allows the development of numerical solution. Our stochastic Petri net solution was encoded using Trivedi's SPNP package, and solutions evaluated for di ering arrival rates, time out intervals, and probabilities of transmission error. No attempt was made to model the e ect of the non exponential nature of time outs or packet transmissions.1 All our experiments used a mean transmission rate of 10 packets per second. This means that the maximum throughput that can be expected of the system is 5 packets per second, since acknowledgments take similar transmission time to packets. The probability of a transmission error was chosen to be either 0.01, 0.05 or 0.1, and the mean time out interval ranged from 0.02 seconds to 2.5 seconds. Maximum throughput when the transmission error probability is 0.01 is 4.37 packets per second, and occurs when the time out interval is 0.5 seconds. When the error probability is 0.1, the maximum throughput obtained is 3.37 packets per second, and occurs when the time out interval is 0.1 seconds. The graph in Figure 14 shows the maximum throughput as a function of the time out interval. It can be seen that when the time out interval is very long, the throughput is low, because any packets which are lost because of transmission errors have a long wait before they are retransmitted. As the interval reduces, the throughput increases. A maximum throughput is reached, and then the throughput decreases slightly, because time outs are occurring too frequently, even when the 1 The TIPP gures simulated a constant timeout interval by using an Erlang-k distribution for the time out. There is no reason other than coding convenience that such a technique was not used in our system.
14
packet has not been lost, and the retransmission of correctly received packets is impeding the use of the channel by the subsequent packet. 4.5 4 0.01 p = 0.05 0.1
3.5 3 2.5
Throughput 2 1.5 1
0
0.5
1
Timeout Interval
1.5
2
2.5
Figure 14: Maximum Throughput as a Function of Time Out Interval
7 Conclusions We have demonstrated that UML speci cations of interacting software processes can be transformed into stochastic Petri nets. Numerical evaluation of these Petri nets can give estimates of the performance of the software. This provides a straightforward link between an existing popular design notation, and performance models of the system being designed. Further work is being undertaken to automate the translation from UML state diagram to Petri net, and to build the performance evaluation capability into a CASE tool. The ultimate aim is to produce a tool in which performance problems can be identi ed early in the design cycle.
References [1] K. Bartlett, R. Scantlebury, and W. Wilkinson. A note on reliable full-duplex transmission over half-duplex links. Communications of the ACM, 12(5):260{261, 1969. [2] F. Bause and P. Buchholz. Protocol analysis using a timed version of SDL. In Proceedings of the 3rd Int. Conf. on Formal Description Techniques (FORTE '90). Springer, 1991. [3] H. Beilner and F.J. Stewing. Concepts and techniques of the performance modelling tool HIT. In Proceedings of the European Simulation Multiconference. SCS Europe, 1987. [4] G. Ciardo, J. Muppala, and K. Trivedi. SPNP: Stochastic petri net package. In Proceedings of 3rd International Workshop on Petri Nets and Performance, pages 142{151, Kyoto, Japan, 1989. [5] Martin Fowler with Kendall Scott. UML Distilled. Addison-Wesley, 1997. [6] D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8:231{274, 1987. 15
[7] Steven Hargreaves. Simulating UML models. Master's thesis, Department of Computer Science, University of Edinburgh, 1998. [8] E. Heck. SDL-HIT integration. In Konlof, editor, Method Integration: Concepts and Case Studies. Wiley, 1992. [9] E. Heck, D. Hogrefe, and B. Moller-Clostermann. Hierarchical performance evaluation based on formally speci ed communication protocols. IEEE Trans. Comp., 40(4):500{513, 1991. [10] H. Hermanns, V. Mertsiotakis, and M. Rettelbach. Performance analysis of distributed systems using TIPP - a case study. In Jane Hillston, Rob Pooley, and Peter King, editors, UKPEW '94, pages 131{144, Edinburgh University, September 1994. UK Performance Engineering Workshop. [11] F.W. Howell and R.McNab. Using Java for discrete event simulation. In Jane Hillston and Rob Pooley, editors, Proceedings of UKPEW '96, pages 219{228, University of Edinburgh, July 1996. UK Performance Engineering Workshop. [12] ITU. ITU-TS Recommendation Z.120: Message Sequence Chart (MSC). ITU-TS, Geneva, 1996. [13] Carina Kabajunga. Support for the uni ed modelling language design paradigm. Master's thesis, Computer Science, University of Edinburgh, 1997. [14] Carina Kabajunga and Rob Pooley. Simulating UML sequence diagrams. In Rob Pooley and Nigel Thomas, editors, UK PEW 1998, pages 198{207. UK Performance Engineering Workshop, July 1998. [15] S.R. Kershaw, N.M. Macintyre, and N. Xenios. A toolset to support the performance evaluation of systems described in SDL. In G. Haring and G. Kotsis, editors, Computer Performance Evaluation - Modelling Techniques and Tools, 7th Int. Conf. on Modelling Techniques and Tools for Computer Performance Evaluation, pages 23{26, Vienna, May 1994. SpringerVerlag. Vienna. [16] M. Ajmone Marsan, G. Balbo, and G. Conte. A class of generalised stochastic Petri nets for the performance evaluation of multi-processor systems. ACM Trans. Comp. Systems, C-31(9):913{917, September 1984. [17] Robin Milner. Communication and Concurrency. International Series in Computer Science. Prentice Hall, 1989. [18] OMG. http://www.rational.com/uml/documentation.html. [19] J.L. Peterson. Petri Net Theory and the Modeling of Systems. Prentice-Hall,, 1981. [20] Rob Pooley and Peter King. The uni ed modeling language and performance engineering. IEE Proceedings - Software, 1999. [21] Rob Pooley and Perdita Stevens. Component Based Software Engineering with UML. Addison-Wesley, November 1998. [22] N. Rico and G.v. Bochmann. Performance description and analysis for distributed systems using a variant of LOTOS. In 10th Int. IFIP Symposium on Protocol Speci cation, Testing and Validation, July 1990. [23] Connie U. Smith. Performance Engineering of Software Systems. Addison-Wesley, Reading, Massachusetts, 1990.
16
[24] Connie U. Smith and Lloyd G. Williams. Performance engineering evaluation of object oriented systems with SPE ED. In R. Marie et al., editor, Computer Performance Evaluation - Modelling Techniques and Tools, 9th Int. Conf. on Modelling Techniques and Tools for Computer Performance Evaluation, number 1245 in LNCS. Springer, 1997. St Malo. [25] A. Valderruten, O. Hjiej, A. Benzekri, and D. Gazal. Deriving queueing networks performance models from annotated LOTOS speci cations. In R. Pooley and J. Hillston, editors, Computer Performance Evaluation - Modelling Techniques and Tools, 6th Int. Conf. on Modelling Techniques and Tools for Computer Performance Evaluation, number 10 in Edits, pages 120{130, Edinburgh, September 1992. Edinburgh University Press. Edinburgh. [26] G. Waters, P. Linington, D. Akehurst, and A. Symes. Communications software performance prediction. In Demetres Kouvatsos, editor, 13th UK Workshop on Performance Engineering of Computer and Telecommunication Systems, pages 38/1{38/9, Ilkley, West Yorkshire, July 1997. BCS Performance Engineering Specialist Group. [27] Lloyd G. Williams and Connie U. Smith. Information requirements for software performance engineering. In H. Beilner and F. Bause, editors, Computer Performance Evaluation - Modelling Techniques and Tools, 8th Int. Conf. on Modelling Techniques and Tools for Computer Performance Evaluation, number 977 in LNCS, pages 86{101. Springer, 1995. Heidelberg.
17
