Structured Language for Specifications of Quantitative Requirements

Transcription

1 Structured Language for Specifications of Quantitative Requirements Mario Dal Cin University of Erlangen-Nuremberg Informatik 3 dalcin@infomatik.uni-erlangen.de Abstract Requirements for dependable systems need to be understandable and, at the same time, have to satisfy consistency and unambiguity properties. We provide a means to specify nonfunctional requirements in terms of structured English sentences. We define their the syntax by a clear and consistent notation. For verification these sentences have to be transformed to a notation that can be interpreted by analysis tools. It is shown how this can be achieved via several translation steps. 1. Introduction Assurance of dependability properties demands to specify and to verify non-functional system requirements. Otherwise, pure functional specifications leave the system s behavior undefined in the presence of a fault. In a quantitative setting it is typically checked whether the probability for a certain property meets a given lower or upper bound. In a risk-based approach these bounds are derived from risk measures. Then, the analysis gives useful information to improve system performance and to reduce risk. However, as computer-based analysis deals with more complex system behavior a rigorous specification language for non-functional, quantitative requirements becomes a prerequisite for this approach. If a mathematical, stochastic-related language is used, it often turns out that engineers even with mathematical background have severe problems to compile correct requirement specifications. In this paper, we introduce a grammar for an English like language which allows to specify non-functional dependability and performance requirements in an unambiguous way. We claim that requirements expressed in this language can easier be communicated to other persons and can be used for documentation purposes. We follow a three-step approach, see Figure 1.1. In the first step, non-functional properties are specified in general terms using a notation called SQIRL. In the second step, this specification is refined within the context of the system model. The final step is required to translate this specification (and the system model) to a notation that can be interpreted by an analysis tool. Requirement Model Reward Functions Figure 1.1 Steps Non-functional Requirements SQIRL Analysis System Model Stochastic Reward Net For the second step we employ in this paper stochastic Petri nets, an alternative could be Statecharts. Stochastic Petri nets have been used successfully to represent systems under design in order to study their performance, safety, reliability and availability [20]. They provide compact representations of Markov processes and reveal concurrent behavior. For the last steps, we use the language of Stochastic Reward Nets (SRN) [11] for which we have developed a powerful analysis tool. This step presumes a well defined transformation from the requirement and

2 system models to the analysis model [12]. The paper is organized as follows. The next section gives a brief overview of related work. Section 3 introduces the basic structure of our language. In section 4 we briefly introduce General Stochastic Petri Nets and give some examples. Thereafter (section 5) we introduce Stochastic Reward Nets and the syntax of property functions. In section 6 the transformation of requirement specifications to Markov reward processes is explained. Finally, in section 7 we briefly present our analysis tool. 2. Related Work A similar problem is encountered in model checking where understanding specifications through means of temporal logic formulae can cause severe problems for the engineer. The effort to acquire an adequate level of expertise in writing these specifications is quite high and represents a substantial obstacle. Some approaches tackle this problem by introducing temporal logic patterns for the representation of frequently identified temporal requirements. They are mostly based on CTL or LTL. A property specification pattern is a generalised description of a commonly occurring requirement for the permissible state/event sequence in a finite-state model of a system. It describes the essential structure of some aspect of a system's behavior in a common formalism [22]. An extensive systematic classification of specification patterns based on CTL for model checking was published in [23]. However, CTLpatterns representing generic properties of some complexity still tend to be hard to understand. Usually an expert in formal logic is required to create and use them. Paper [13] introduces patterns for the specification of properties in structured English. Each pattern corresponds to a Clocked CTL formula. Clocked CTL is a variant of timed CTL. Paper [21] presents a graphical language for specification of properties of real-time systems which is again based on CTL. Two levels of compiling specifications are proposed. At the first level, an expert constructs partial formulae that capture the user`s intuition for the problem domain. At the second level, the user uses the patterns provided by the experts at the first level, to express properties of his system. Stochastic model checking has been discussed in [9,18] introducing a branching temporal logic called Continuous Stochastic Logic (CSL) to express quantitative requirements for continuous-time Markov process models. The logic is an extension of the equally named logic of [7]. Apart from the usual path formulae like next and until, a time-bounded until and a time-bounded eventually together with probabilistic operators are incorporated. In [17] an implementation of probabilistic CTL model checking using symbolic techniques is presented. In [16] a language called SPNL is defined which combines textual and graphical elements and provides a reward concept. A powerful concept for specifying rewards for Petri nets has also been discussed in [15], however, without saying how to implement it. 3. Stochastic Quantitative Requirement Language In this section, we introduce a structured Englishoriented notation as a user front-end for the specification of non-functional requirements. We refer to this language as the stochastic quantitative requirement language (SQIRL). Using this notation the user can compile English sentences from a list of English fragments. The sentences represent (stochastic) requirements which are the basis for the evaluation of stochastic models. Non-functional requirements given in structured English can easier be communicated to other persons. Furthermore, structured English sentences are non-ambiguous and, therefore, can be used for documentation purposes. Note, that SQIRL sentences are independent of the modeling language used, e.g. Statecharts or Petri nets, and the concrete system model. To define their precise semantics they have, therefore, to be translated to the modeling environment. Our language has a very simple basic structure. Figure 3.1 gives the definition of its syntax. <requirement> ::=< query>[<constraint>]. <constraint> ::= (= < > )REAL <query >::= [If <condition> Then] <measure>[<timescope>] <measure> ::= ( [cumulative ]probability [accumulated] expectation variance) of <domain> <timescope> ::= at time REAL within time interval REAL to ( REAL infinity ) <domain> ::= <property>[until <property>] <property>::= <property>{(and or)<property>} For condition and property see below. Reals are positive. Figure 3.1 SQIRL Each requirement is a query followed by an optional constraint, often a probability limit. A requirement without a constraint is a query and the request for a computation. Query specifies a measure with an optional time scope. If no time scope is specified all times are set to infinity, that is, the measure refers to 2

3 the steady state of the system s model. The first part of a query (condition) is a fragment which specifies an initial condition for the system. We refer to the initial condition, as given by the modeler of the system, as ' initial_condition '. (Then the fragment `If initial_condition Then can be omitted in the requirement specifications.) The non-terminal property is a fragment (or a sequence of fragments) defining a nonfunctional property of the system like throughput, availability or reliability. Let us look at some examples of structured SQIRL sentences. In this paper we are mainly interested in dependability properties and less in performance. Therefore, we will not use fragments like `(accumulated) expectation of. Here we assume that properties like the fragments system functioning, system up, or repaired as well as the condition power down are defined elsewhere (Section 4 and 5). A simple query is: probability of system functioning. which means that the steady state availability is to be computed. Next, we can specify the requirement: probability of system functioning 0.9. which means that the steady state availability of the system should not be less than 0.9. Sentence cumulative probability of system_up within time interval 0 to infinity. denotes the mean time to failure and may be abbreviated as MTTF. An other example is : If power down Then system functioning until repaired > Next we show how system properties can be specified within the context of a system model. We do this within the context of Generalized Stochastic Petri Nets. We assume that the reader is familiar with Stochastic Petri Nets. Stochastic Petri Nets have been used successfully to represent systems under design in order to study their performance, safety, reliability and availability [20]. 4. Generalized Stochastic Petri Nets Generalized Stochastic Petri Nets (GSPN) are generalizations of Stochastic Petri Nets allowing transitions to have either zero firing times (immediate transitions) or exponentially distributed firing times (timed transitions). Immediate transitions which can be simultaneously enabled must have probabilities assigned. For timed transitions, the decision as to which transition fires next is decided by a race; the transition with the minimal delay prior to firing will fire next. Firing of immediate transitions has priority over firing timed transitions. Other extensions include inhibitor arcs (arcs with dots). In [1] it is shown that a GSPN is equivalent in modeling power to a continuous time Markov chain. Figures 4.1 and 4.2 present two simple examples of GSPNs. (Immediate transitions are depicted by solid bars and timed transitions by light bars.) These examples will serve us later on to illustrate our concepts. λ 1 Busy 1 Serve γ 1 1 Idle 1 µ 1 µ 2 γ 2 Poll 1 Poll 2 Serve 2 Busy 2 λ 2 Idle 2 Figure 4.1 Cyclic polling system Rates: µ i service rate, λ i transaction rate, γ i poll rate The example is taken from [20]. The system consists of two stations and one server. Place Idle i represents the event that station i is idle, and place Busy i represents the event that station i has generated a job for the server. The server visits the two stations in a cyclic manner. It first polls a station and then serves it. The times for generating a job, for polling and for serving are exponentially distributed with parameters λ i, γ i and µ i, respectively. In case that the server finds a station idle, service time is zero; that is, the server skips the station. This is modeled by the immediate transitions (and outgoing inhibitor arcs of places Busy). Our next example models a queuing system, Figure 4.2. The tokens in place Wait represent (at most K) jobs waiting for processing. Initially there are K tokens in place Wait. The server is operating if at least one token is in place Serve. The server failed, if a token is in place Down. The server can fail only when it is busy. The served job is served again (with probability p) when the server is repaired, or put back into the Waitqueue (with probability 1-p). Wait K α 1-p p Serve Rest λ β Up Down ρ repairing Figure 4.2 Queuing system with server breakdown 3

4 Rates: α arrival rate, β service rate, λ failure rate, ρ repair rate Within the context of GSPNs, the non-terminal condition in Figure 3.1 is defined as Boolean expression like sentence fragments in terms of: token`( <place_identifier>`) [INTEGER token`( <place_identifier>`) ], rate`( <transition_identifier>`) REAL enabled`( <transition_identifier>`), fire`( <transition_identifier>`), where is an element of { =, <, >,, }. Boolean operators are represented by the terminals : and, or, not. The term token(place_identifier) >0 can be substituted by the fragment in < place_identifier>. The non-terminal property in Figure 3.1 is defined as : <property> ::= <condition> {for (rate prob)`( <transition_identifier>`) = REAL } where the second part allows to redefine firing rates and firing probabilities. (This is necessary to compute, for example, the reliability of a system.) Referring to Figure 4.1, we then can, for example, specify: probability of not in Serve 2 until in Serve 1 within time interval 0 to 20 > That is, up to time 20, station 1 should be served before station 2 with probability greater than More precisely, the sentence asserts, that with probability greater 0.81 there is some x ε [0,x] such that not in Serve 2 continously holds during [0,x] and in Serve 1 becomes true at time instant x. For the steady state we can specify: probability of in Busy 1 and not in Serve 1 < 0.5. That is, in steady state, the probability of station 1 waiting to be served should be less than 0.5. The sentence If in Busy 1 and in Busy 2 Then probability of in Serve 1 at time 4 > means that if both stations are busy at time 0, station 1 should be served at time 4 with probability greater than 0.9. Referring to Figure 4.2, query availability, defined as probability of in Up., requires to compute the steady state probability π Up, whereas reliability queries require to compute the transient state probability π Up (t) for a given time under the assumption that the repair rate ρ is zero (required by the definition of reliability). That is, reliability at time 100 is specified as: probability of in Up for rate(repairing) = 0 at time 100. Sentence: If token(wait) = K and in Down then probability of fire(repairing) within time interval 0 to 5 > 0.7. means that the repair of a failed empty server should take at most 5 time units with probability greater than 0.7. A requirement for the accumulated expectation of idle times may be specified as : If token(busy 1 )=2 and token(busy 2 )=1 Then accumulated expectation of some_idle within time interval 0 to 300 < Stochastic Reward Nets In order to be able to mechanicaly compute a query or to check a requirement we translate properties to reward functions of Stochastic Reward Nets (SRN), see Figure 1.1. SRNs are a superset of GSPNs and substantially increase the modeling power of GSPNs. Extensions include guards, marking dependent arc multiplicities, general transition priorities, marking dependent firing rates for transitions, and reward rates. A guard is a predicate associated with a transition. Whenever a transition is otherwise enabled (in some marking), the guard is evaluated before finally enabling the transition. Marking dependent arc multiplicity allows to specify the number of tokens (in input or output places) required for a transition to be enabled. This number can be a function of the current marking. SRNs provide the same modeling power as Markov reward processes [10]. 5.1 Reward Functions In this section we define the semantics of SQIRLproperties in terms of their translation to so-called reward functions. Names of property fragments become now names of reward functions. In other words, in the context of SRN, the semantics of property fragments is given by reward functions. A reward function assigns numbers to certain model states. For example, it may assign 1 to all states where the system is up and 0 to all states where the system is down. These numbers are then used to compute 4

5 quantitative, non-functional measures, for example, probability measures. The syntax of reward functions is defined in Figure 5.1. <rewardfunction> ::= For (<statecondition> < transitioncondition>) Reward is < reward > Else <reward>. <reward >::= REAL token`( <place_identifier> `) [ x REAL] <transitioncondition> ::= fire`( <transition_identifier>`) {or fire`( <transition_identifier>`) } [<statecondition>] The non-terminal statecondition is a Boolean expression like sentence in terms of: token`( <place_identifier>`) [INTEGER token`( <place_identifier>`) ] enabled`( <transition_identifier>`) transient`( <place_identifier>`) absorbing`( <place_identifier>`) rate`( <transition_identifier>`) INTERGER Figure 5.1 Syntax of reward functions A place is absorbing, if it has no outgoing arcs to transitions with firing rate > 0 connected to other places. A place is transient, if it has ingoing and outgoing arcs. The property fragments for rate(t) = 0 and for prob(t) = 0 require that the transition rate and transition probability, respectively, is set to 0 before evaluation. Then a transient place may become absorbing. 5.2 Examples Let us again look at some simple examples. P is a place identifier, Ti are transition identifier. For token(p) > 1 and absorbing(p) Reward is token(p) x 10 Else 1. For fire(t1) or fire(t3) in P or enabled(t3) Reward is 5.5 Else 0. Referring to Figure 4.1, property some_idle is defined by reward function For token(idle 1 ) > 0 or token(idle 2 ) > 0 Reward is 1 Else 0. Referring to Figure 4.2, obviously property system functioning is defined by the reward function For token(up) = 1 Reward is 1 Else 0. Each SRN model can be converted to an equivalent Markov reward model. Each distinct marking of a SRN constitutes a state of the Markov reward process. These states are classified into two types: tangible and vanishing. A state is tangible if the only net transitions enabled in this state are timed transitions. A state is vanishing if one or more immediate net transitions are enabled in this state. 6. Transformation We have to distinguish between the net level description (N-level) and the Markov process level description (M-level). On the N-level we speak about places, net transitions, tokens, guards, markings, or capacities; on the M-level we speak about states and state-transitions. Requirements and reward functions are specified at N- level. For their evaluation, they have to be translated to M-level descriptions. So called state rewards and impulse rewards are defined at M-level. A state reward r i (reward rate) is obtained when the system is in state i and a impulse reward i ls k is obtained when the system takes transition k from state l to state s (There may be several transitions from state l to state s due to the firing of different net transitions.) State rewards define values (per unit of time) that are collected while the stochastic process spends time in a certain state; impulse rewards specify the reward that is gained when a certain state transition takes place due to the firing of a certain net transition. A reward function with statecondition defines state rewards; a reward function with transitioncondition defines impulse rewards. The transformation from N-level to M-level can be achieved by employing so-called characterising functions [2,6]. This transformation can be done automatically by an analysis tool. Characterising functions are the means to transfer information from N-level to M-level by connecting places and net transitions with states and state transitions. With these functions reward measures can be generated. Examples of characterising functions are: mark(p,s) returns the number of tokens of place p in state s, enabled(t,s) is true, if net transition t is enabled in state s otherwise it is false, fire(t,st) is true, if net transition t is responsible for state transition st. After the continuous time Markov chain (CTMC) has been generated from the net model, the characterising functions can be used to assign to each state and state transition a state and impulse reward, 5

6 respectively, as defined by the reward function. For an automatic evaluation, each state and state transition of the CTMC is annotated with the corresponding values of the characterising functions, so that, the reward conditions can be checked when computing queries. Sometimes it is necessary to automatically modify the net model before generating the CTMC. This is the case if the requirement contains the fragment 'If condition Then' or, if the reward function contains the fragment 'for rate...'. Similarly, if 'property1 until property2' is specified, all states for which property1 does not hold become absorbing states of the CTMC. When the state rewards r k and the impulse rewards i k have been generated, queries can be computed. For example, let property p define the reward function r. Furthermore, assume that reward function r in turn defines state rewards r k = 0 or 1, as it is often the case in dependability analysis. Then the query: probability of p at time t is computed as E(r(t)) = Σ r i π ι (t) where π i (t) is the transient state probability of the CTMC and the sum runs over all states of the CTMC. The general formula for the expectation of reward r at time t is: E(r(t)) = Σ r i π i (t) + Σ i kl i t k π k (t) where i kl i is an impulse reward and t k the state transition rate. The second sum is over all state transitions of the CTMC. 7. Tool support A tool that uses SQIRL as front-end to express and evaluate properties of stochastic models is being implemented as part of our analysis tool PANDA (Petri Net Analysis and Design Assistant). PANDA contains an UML- interface and an automatic mapping of UML dynamic models to Stochastic Reward Nets [12]. This UML-interface allows visually modeling system behavior by UML diagrams. PANDA [2,3,4,5] accepts not only exponential distribution functions, but also non-exponential ones (Erlang-k, Gamma, Weibull, Normal, Lognormal, Hyperexponential, etc.). Disregarding result measures, the net definition of PANDA is done in CSPL which is the C-code description language for Petri Nets used by the SPNP tool [11]. Dependability measures can be specified by reward functions. To this end, a stringent and clear reward concept has been developed based on reward rates and impulse rewards combining knowledge of the net model and the state space. That is, the net view is not lost when defining reward functions on the state space. PANDA is available for shared and distributed memory platforms. PANDA provides the following characterizing functions: long mark(char *placename) returns the number of tokens in place placename in the current marking, int enabled(char*transname) returns 1 if transition transname is enabled in the current marking and 0 otherwise, int absorbing(void) returns 1 if the current marking is absorbing and 0 otherwise, double rate(char*transname) returns the firing rate of transition transname if it is responsible for the current state transition and 0.0 otherwise, int fire(char *transname) returns 1 if the transition transname is responsible for the current state transition, 0 otherwise, void probval(char *transname, double value) sets the firing weight of transition transname to value and makes the transition an immediate transition, void rateval(char transname, double lambda) sets the firing rate of transition transname to lambda and makes the transition a timed, exponentially distributed transition, etc. The current marking is the missing parameter in these characterizing functions; it is set dynamically during state space generation or during the evaluation of the requirements. Other useful functions include, for example, void init(char *placename, unsigned int ntoken) initializes place placename with ntoken tokens. type_result expected(double (*rrew_fn)(), double (*irew_fn)()) returns the expected reward given by the state reward function rrew_fn and by the impulse reward function irew_fn which assign rewards to states and state transitions, respectively. Reward functions are translated to the corresponding functions built from these characteristic functions. PANDA then automatically computes the reward rates and the impulse rewards, defined by the reward function, and computes the result measures. That is, it computes rewards at a point in time (e.g. availability or throughput) as well as accumulated rewards. The development of PANDA has been part of the HIDE project [8,19] of the European Community. 7.Conclusion Due to the high level of complexity of real life models, modeler need support allowing to express desired model properties in a concise but understandable and unambiguous way. We presented a clear and consistent language for the specification of nonfunctional requirements and showed how to translate it to a representation suitably for analysis tools. 6

7 8. References [1] M. Ajmone Marsan, et al. (1986): Performance Models of Multiprocessor Systems, The MIT Press, [2] S. Allmaier, Parallele Lösungen für stochastische Modellierung, PhD thesis, Arbeitsberichte des IMMD, Nr13, Erlangen 1999 [3] S. Allmaier, D. Kreische, PANDA Petri Net Analysis and Design Assistant User's Guide, technical report 1/2000 Informatik 3 University of Erlangen [4] S. Allmaier, S. Dalibor, D. Kreische, Parallel graph generation algorithms for shared and distributed memory machines, Proc. Parallel Computing: Fundamentals, Applications and New directions, Vol 12 of Advances in Parallel Computing, pp , Elsevier, [5] S. Allmaier, D. Kreische, Parallel approaches to the numerical transient analysis of stochastic solution of GSPNs on a shared memory multiprocessor, Proc. IEEE Int. Workshop on Petri Nets and Performance Models (PNPM'97), [6] S. Allmaier, S. Dalibor (1997): PANDA -- Petri net ANalysis and Design Assistant, Tools Descriptions, 9th Int. Conf. on Modeling Techniques and Tools for Computer Performance Evaluation, St. Malo, [7] A. Aziz et al., Verifying continuous time Markov chains, Proc. Computer-Aided Verification, SLNCS 1102, , Proc. Fourth IEEE Int. High-Assurance System engineering Symposium (HASE'99 [8] A. Bondavalli, M. Dal Cin,, D. Latella, A. Pataricza, High-level integrated desin envoronment for dependability (HIDE), IEEE Proc. WORDS'99, [9] C. Baier, J.-P. Katonen, H. Hermanns, Approximate symbolic model checking of continuous-time Markov chains, Proc. Concurrency Theory, SLNCS 16664,pp , [10] G. Ciardo, et al., Automated generation and analysis of Markov reward models using Stochastic Reward Nets, Linear Algebra, Markov Chains and Queueing Models, Springer, 1992 [14] M.D Fraser, K. Kumar, V.K. Vaishnavi, Strategies for incorporating formal specifications in software development, Communications of the ACM, Vol 37, pp 74-86,1994 [15] F. German et al., Expected impulse rewards in Markov regenerative stochastic Petri nets Proc. 9 th Conf. Computer Performance Evaluation, Modelling Techniques and Tools, SLNCS, [16] F. German, SPNL: processes as language-oriented building blocks of stochastic Petri nets, Proc. 3 rd Int. Workshop Petri Nets and Performance Models (PNPM'97), SLNCS 1245,1997. [17] V. Haronas-Garmhause, S. Campos, E. Clarke, ProbVerus: Probabilistic Symbolic Model Checking, Proc ARTS'99,SLNCS 1601, pp , [18] H. Hermanns, et al. A markov chain model checker, Informatik 7, University of Erlangen, [19] HIDE: High-level Integrated Design Environment for Dependability, University of Erlangen-Nuremberg (FAU- IMMD3), Consortio Pisa Ricerche - Pisa Dependable Computing Centre (PDCC), Technical University of Budapest (TUB-MIT), MID GmbH, INTECS Sistemi S.p.A. [20] O.C. Ibe, K.S. Trivedi, Stochastic Petri net models of polling systems, IEEE J. On Se. Areas in Comms., pp , [21] I. Lee, O. Sokolsky, A graphical property specification language, Proc. IEEE Int. High-Assurance System engineering Symposium (HASE'97) pp ,1997. [22] B. Matthiew et al., Property specification patterns for finite-state verification, Proc. 2 nd Workshop on Formal Methods in Software Practice, [23] B. Matthiew et al., Property specification patterns for finite-state verification, Proc. 21. Int. Conf. on Software Engineering, [11] G. Ciardo, J. Muppala, K.S. Trivedi, SPNP: Stochasic Petri Net package, Proc IEEE Int Workshop on Petri Nets and Performance Models (PNPM'89) pp , [12] M. Dal Cin, G. Huszerl, K. Kosmidis, Qualitative evaluation of dependability critical systems based on guarded statechart models, Proc. Fourth IEEE Int. High-Assurance System engineering Symposium (HASE'99), pp 37-45, [13] S. Flake, W. Mueller, J. Ruf, Structured English for model checking specifications, Proc. Methoden u. Beschreibungssprachen zur Modellierung u. Verifikation von Schaltungen u. Systemen, VDE Verlag 2000B. 7