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

Bibliography [1] https://pdfs.semanticscholar.org/bb06/0202d9915c9074864bca1f126e942968624c.pdf [2] http://dl.acm.org/citation.cfm?id=1071025 [3] http://www.omg.org/spec/SPTP/1.1/ Marek Bazan Katedra K9/W4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 176-177) Marek Bazan Katedra K9/W4

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

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