Download
1 / 48
480 likes | 601 Vues
Requirements engineering –IDY0201Lecture 12- Formal methods Enn Õunapuu enn@cc.ttu.ee. Definition. Generally speaking, a formal specification is the expression, in some formal language and at some level of abstraction, of a collection of properties some system should satisfy. Process.
E N D
Requirements engineering –IDY0201Lecture 12- Formal methodsEnn Õunapuuenn@cc.ttu.ee
Definition Generally speaking, a formal specification is the expression,in some formal language and at some level of abstraction, ofa collection of properties some system should satisfy.
Process Complex software applications are built using a series ofdevelopment steps: high-level goals are identified andrefined until a set of requirements on the software andassumptions on the environment can be made precise to satisfysuch goals; a software architecture, made of interconnectedsoftware components, is designed to satisfy suchrequirements; and the various components are implementedand integrated so as to satisfy the architecturaldescriptions.
What are good specifications Writing a “correct” specification is very difficult – probablyas difficult as writing a correct program. A specificationmust be adequate, that is, it must adequately state the problemat hand. It must be internally consistent, that is, it musthave a meaningful semantic interpretation that makes true allspecified properties taken together. It must be unambiguous,that is, it may not have multiple interpretations of interestmaking it true. It must be complete with respect to higherlevelones, that is, the collection of properties specified mustbe sufficient to establish the latter. It must be satisfiedby lower-level ones. It should be minimal, that is, itshould not state properties that are irrelevant to the problemor that are only relevant to a solution for that problem.
Why specify formally? to derive premises or logical consequences of the specification,for user confirmation, through deductive theorem proving techniques [Owr95, Man96]; to confirm that an operational specification satisfies moreabstract specifications, or to generate behavioral counterexamplesif not, through algorithmic model checkingtechniques [Que82, Cla86, Hol91, Hol97, McM93, Atl93, Man96, Hei98a, Cla99]; to generate counterexamples to claims about a declarative specification [Jac96]; to generate concrete scenarios illustrating desired or undesired features about the specification [Fic92, Hal95, Hal98];
Why specify formally? to produce animations of the specification in order tocheck its adequacy [Hek88, Har90, Dub93, Doug94, Heit96, Tho99]; to check specific forms of specification consistency/completeness efficiently [Heim96, Heit96]; to generate high-level exceptions and conflict preconditionsthat may make the specification unsatisfiable [Lam98b, Lam2K]; to generate higher-level specifications such as invariantsor conditions for liveness [Lam79, Ben96, Par98, Jef98]; to drive refinements of the specification and generate proof obligations [Car90, Abr96, Dar96]; to generate test cases and oracles from the specification [Ber91, Ric92, Roo94, Wey94, Man95]; to support formal reuse of components through specification matching [Kat87, Reu91, Mas97, Zar97].
Specification paradigms:History-based The principle here is to specify a system by characterizingitsmaximal set of admissible histories (or “behaviors”) overtime. The properties of interest are specified by temporallogic assertions about system objects; such assertionsinvolve operators referring to past, current and future states.The assertions are interpreted over time structures. Time can be linear [Pnu77] or branching [Eme86]. Time structures canbe discrete [Man92, Lamp94], dense [Gre86], or continuous[Han91]. The properties may refer to time points [Man92,Lam94], time intervals [Mos97], or both [Gre86, Jah86,All89, Ghe91]. Most often it is necessary to specify properties over time bounds; real-time temporal logics are thereforenecessary [Koy92, Dub91, Mor92, Dar93, Mos97].
Specification paradigms:State-based Instead of characterizing the admissible system histories,one may characterize the admissible system states at somearbitrary snapshot. The properties of interest are specified by • invariants constraining the system objects at any snapshot, • pre- and post-assertions constraining the applicationof system operations at any snapshot. A pre-assertioncaptures a weakest necessary condition on input states forthe operation to be applied; a post-assertion captures a strongesteffect condition on output states if the operation isapplied. The latter may be explicit or implicit dependent onwhether or not the assertion contains equations defining the output constructively. Languages such as Z [Abr80, Spi92, Pot96], VDM [Jon90]or B [Abr96] relyon this paradigm. Object-oriented variantshave been proposed as well [Lan95].
Specification paradigms:Transition-based Instead of characterizing admissible system histories or systemstates, one may characterize the required transitionsfrom state to state. The properties of interest are specified bya set of transition functions in the state machine transition;the transition function for a system object gives, for eachinput state and triggering event, the corresponding outputstate. The occurrence of a triggering event is a sufficient conditionfor the corresponding transition to take place (unlike aprecondition, it captures an obligation); necessary preconditionsmay also be specified to guard the transition. Languages such as Statecharts [Har87], PROMELA[Hol91], STeP-SPL [Man92], RSML [Lev94] or SCR[Par95, Heit96] rely on this paradigm.
Specification paradigms:Functional The principle here is to specify a system as a structured collectionof mathematical functions. Two approaches may be distinguished. Algebraic specification. The functions are grouped by objecttypes that appear in their domain or codomain, thereby defining algebraic structures (or abstract data types). The propertiesof interest are then specified as conditional equationsthat capture the effect of composing functions (typically, compositions with type generators). Languages such as OBJ [Fut85], ASL [Ast86], PLUSS [Gau92] or LARCH [Gut93] rely on this paradigm.
Specification paradigms:Functional Higher-Order Functions. The functions are grouped intological theories. Such theories contain type definitions (possiblyby means of logical predicates), variable declarations,and axioms defining the various functions in the theory.Functions may have other functions as arguments which significantlyincreases the power of the language. Languagessuch as HOL [Gor93] or PVS [Cro95, Owr95] rely on this paradigm.
Specification paradigms: Operational At the extreme opposite, a system may be characterized as astructured collection of processes that can be executed bysome more or less abstract machine. Early languages such as Paisley [Zav82], GIST [Bal82], Petri nets or process algebras [Hoa85, Mil89] rely on this paradigm.
What to use when? As noted before, each paradigm above has some built-in semantic biasin order to be useful.State-based and functional specificationsfocus on sequential behaviors while providing richstructures for defining complex objects. They are thus bettertargeted at transactional systems. Conversely, history-based,transition-based specifications and operational specificationsfocus on concurrent behaviors while providing only fairlysimple structures for defining the objects being manipulated.They are thus better targeted at reactive systems. There are,of course, hybrid approaches that attempt to recover from this, e.g., [Fau92, Geo95].
Examples A recent, fairly impressive example is worth pointing out[Beh99]. The Paris metro system has recently opened a newline (line 14, Tolbiac-Madeleine). The traffic on this line isentirely controlled by software. Driverless trains and conventionaltrains are both supported. The safety-critical componentsof the software (located on board, along the track, andon ground) were formally developed by Matra Transportusing the B abstract machine method [Abr96]. The developmentincludes abstract models of those components, refinementsto concrete models, and automated translation to ADA code. According to [Beh99], there are about 100,000 lines ofB specification, covering the abstract and the concretemodel, and 87,000 lines of ADA code. The refinement wasentirely validated by formal proofs. The B tool automaticallyproved 28,000 lemmas and 65% of the rules added to dischargeproofs. Many errors were found thereby, and fixed inthe concurrent development. In addition, a conventional testingprocess was deployed and not a single error was found.
Domain Engineering: The Engineering Dogma Before software can be designed we must know its requirements. Before requirements can be expressed we must understand the domain. So it follows, from our dogma, that we must – first establish precise descriptions of domains; – then from such descriptions, “derive” at least domain and interface requirements; – and from those and machine requirements design the software, or, more generally, the computing systems.
Domain engineering process We see the domain engineering process as composed from, and iterated over the following stages: 1. identification of and regular interaction with stakeholders 2. domain (knowledge) acquisition 3. domain analysis 4. domain modelling 5. domain verification 6. domain validation
Entities, Functions, Events and Behaviours We shall analyse phenomena and concepts according to the following simple, but workable classification: entities, functions (over entities), events (involving changes in entities, possibly as caused by function invocations, i.e.,actions, and/or possibly causing such), and behaviours as (possibly sets of)sequences of actions (i.e., function invocations) and events.
Entities By an entity we shall understand something that we can point to, somethingmanifest, or a concept abstracted from such phenomena or concepts. Entities are either atomic or composite. The decision as to which entities areconsidered what is a decision solely taken by the describer. • By an atomic entity we intuitively understand an entity which ‘cannot betaken apart’ (into other, the sub-entities).
Mereology By mereology we shall understand a theory of part-hood relations. That is,of the relations of part to whole and the relations of part to part within a whole. The term mereology seems to have been first used in the sense we are usingit by the Polish mathematical logician Stanis law Le´sniewski [54, 72].
Composite Entities By a composite entity we intuitively understand an entity (i) which “can betaken apart” into sub-entities, (ii) where the composition of these is describedby its mereology, and (iii) which further possess one or more attributes.
States By a domain state we shall understand a collection of domain entities chosen by the domain engineer. The pragmatics of the notion of state is that states are recurrent argumentsto functions and are changed by function invocations.
Functions By a function we shall understand something which when applied to someargument values yield some entities called the result value of the function (application). By an action we shall understand the same things as applying a state-changingfunction to its arguments (including the state).
Events By an event we shall understand an instantaneous change of state not directlybrought about by some explicitly willed action in the domain, but either by“external” forces. or implicitly as a non-intended result of an explicitly willed action. Events may or may not lead to the initiation of explicitly issued operations.
Behaviours By a behaviour we shall understand a structure of actions (i.e., functioninvocations) and events. The structure may typically be a set ofsequences of actions and events. We here refrain from stating whether the “set of sequences” is supposed tomodel interleaved concurrency, as when we express concurrency in terms ofCSP, or is supposed to model “true” concurrency, as when we express concurrency in terms of Petri Nets. Such a statement is required, or implied,however, whenever we present a particular model. A behaviour is either a simple behaviour, or is a concurrent behaviour, or,if the latter, can be either a communicating behaviour or not.
Formal modelling of behaviours Communicating behaviours, the only really interesting behaviours, can be modelled in a great variety of ways: fromset-oriented models in B, RSL, VDM, or Z, to models using for exampleCSP (as for example “embedded” in RSL), or, to diagram models using, forexample, Petri nets, message or live sequence charts, or Statecharts.
Domain facets By a domain facet we shall understand one amongst a finite set of genericways of analysing a domain: a view of the domain, such that the differentfacets cover conceptually different views, and such that these views together cover the domain. The hedge here is “finite set of generic ways”. Thus there is an assumption,a conjecture to be possibly refuted. Namely the postulate that there is afinite number of facets. We shall offer the following facets: intrinsics, supporttechnology, management and organisation, rules and regulations (and scripts), and human behaviour.
Process Algebra System behaviour generally consists of processes and data. Processes arethe control mechanisms for the manipulation of data. While processes are dynamic and active, data are static and passive.
Example Each process Pi sends messages to its neighbouring processes Pi¡1 and Pi+1,giving them information on the state of Pi. The neighbouring processes usethis information in their internal computations, to update their own states.
Literature procalg.pdf lamsweerde.pdf facs-domain.pdf
