1. Modelowanie i analiza systemów informacyjnych Performance evaluation of a software UML design
Marek Bazan
Kwiecień 2017

2. Bibliography
[1] [2] [3]
Marek Bazan
Katedra K9/W4

3. Contents Performance modelling • Capturing performance requirements.
• Associating performance-related QoS characteristics with selected elements of a UML model.
• Specifying execution parameters that used by modellers to predict performance characteristics.
• Presenting performance results computed by modeling tools or found in testing.
Marek Bazan
Katedra K9/W4

4. Modelling tools - modellers
Typical tools for this kind of model analysis provide two important functions:
The first is to estimate the performance of a system instance, using some kind of model.
The second function is assistance with determining how the system can be improved, by identifying
bottlenecks or critical resources
Marek Bazan
Katedra K9/W4

5. Background
Scenario - elements of scenarios, and are joined in a sequence, with predecessor-successor relationships that may include forks, joins, and loops.
Each step also has a mean execution count, which is the mean number of times it is repeated when it is executed, and a host execution demand for its host device
Marek Bazan
Katedra K9/W4

6. Background (2) Resource demands Host execution time
Demands of all substeps
Resources
Modelled as servers
Active resources – usual servers with a service times (page 160)
Passive resources – holding times – protected by an access mechnaism e.g. semaphore (page 161)
Marek Bazan
Katedra K9/W4

7. Background (2.5)
Workload – specifies the intensity of demand for the execution of the specific scenario
- OpenWorkload – modeled as a stream of requests that arrive at a given rate
- ClosedWorkload – fixed number of active users
[3] Page 162
Marek Bazan
Katedra K9/W4

8. Background (3) Resource operations Service time = host execution time
Steps or sequence of steps which require the resource
Service time = host execution time
Performance measures
Utilization
Waiting times
Response time
Marek Bazan
Katedra K9/W4

9. Background (4) Performance measures are specified as
A required value, coming from the system requirements or a performance budget based on them (e.g., a required response time for a scenario).
An assumed value, based on experience (e.g., for an execution demand or an external delay).
An estimated value, calculated by a performance tool and reported back into the UML model.
A measured value.
Marek Bazan
Katedra K9/W4

10. Background (5) Performance measures are reported as
Further, the reported value is one of several possible statistical properties of the given measure,
average,
maximum
xth percentile (90th percentile meaning that
90% of values are smaller than this).
Marek Bazan
Katedra K9/W4

11. Performance analysis methods
Queueing models
Simulation models
Discrete-state models – Petri Nets
Marek Bazan
Katedra K9/W4

12. Domain model Performance analysis is always instance-based.
Performance context - one or more scenarios that are used to explore various dynamic situations involving a specific set of resources, e.g.
„busy hours”/”peak hours”
[3] Page 156
Marek Bazan
Katedra K9/W4

13. Domain Concepts into UML Equivalents
Collaboration graphs
Activity graphs
Marek Bazan
Katedra K9/W4

14. Collaboration-based approach
Performance context <-> stereotype «Pacontext»
Scenario (page 179) <-> any performance attributes of a scenario (such as its workload specs) will be attached to the first (root) model element
Step <-> action sterotyped «PAstep»
Marek Bazan
Katedra K9/W4

15. Collaboration-based approach (2)
Workload <-> sterotype of the first step of the scenario – PAclosedworkload, PAopenedworkload
Processing resources <-> sterotype «deploy» - page 175)
Passive resources <-> sterotype «PAresource»
Marek Bazan
Katedra K9/W4

16. Activity-based approach
Performance context <-> stereotype «PAcontext»
Scenario <-> single scenario per context
Scenarios are modeled by the set of states/activities and transitions of the activity graph.
The workload information is attached to this step, which is stereotyped appropriately («PAopenLoad» or «PAclosedLoad»).
Step <-> action sterotyped «PAstep»
The successor set of a step is identified by the action or subactivity states that are directly linked to thatstep by transitions (or, possibly, via pseudostates).
Marek Bazan
Katedra K9/W4

17. Activity-based approach (2)
Step <-> action sterotyped «PAstep»
- The successor set of a step is identified by the action or subactivity states that are directly linked to thatstep by transitions (or, possibly, via pseudostates).
- The initial action or subactivity state may also be stereotyped as a «PAopenLoad» or «PAclosedLoad» as appropriate.
Marek Bazan
Katedra K9/W4

18. Activity-based approach (3)
Workload <-> action sterotyped «PAstep»
- The successor set of a step is identified by the action or subactivity states that are directly linked to thatstep by transitions (or, possibly, via pseudostates).
- The initial action or subactivity state may also be stereotyped as a «PAopenLoad» or «PAclosedLoad» as appropriate.
Marek Bazan
Katedra K9/W4

19. Activity-based approach (4)
Processing resources <-> two ways of modelling
1. Stereotype «PAHost» association with an activity graph partition – when each classifier role is executed on its own host.
2. More common situation is when each partition is executed on different resource – then we use «deploys» relationships to nodes that are stereotyped as hosts (see ProcessingResource section on page 166 an link to exmaple)
Marek Bazan
Katedra K9/W4

20. Activity-based approach (5)
Passive resources <-> two ways of modelling
1. Partitions stereotyped by «Paresource» visualized as swimlanes
2. Alternatively, they may be modeled indirectly by specifying one or more PAextOp tagged values for the steps that access those resources. (For an example, see the “sendFrame” page 181.)
Marek Bazan
Katedra K9/W4

21. Modeling Guidelines and Examples - Just diagrams
Web Video Application ([3] page 173) – general structure
The deployment of the logical elements across the engineering environment ([3] page 174)
Collaboration-based Approach – Sequence diagram ([3] page 174)
Activity-based Approach – Hierarchical activity diagram ([3] page )
Marek Bazan
Katedra K9/W4

22. Modeling Guidelines and Examples – Performance anotations
Sequence diagram [3] page 179
Activity diagrams [3] page
Quality of service requirements (QoS) [3] page 181
Marek Bazan
Katedra K9/W4

23. Performance evaluation of a software UML design
Thank you for your attention