Math & Engineering

A framework for software problem analysis

Description
A framework for software problem analysis
Published
of 11
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  ISSN 1744-1986 Technical Report N o 2005/05  A framework for software problem analysis Jon G. Hall Lucia Rapanotti 7 th  April 2005 Department of Computing   Faculty of Mathematics and Computing The Open University Walton Hall, Milton Keynes MK7 6AA United Kingdom http://computing.open.ac.uk l    A framework for software problem analysis Jon G. Hall Lucia RapanottiComputing Research CentreThe Open University ABSTRACT The paper introduces a software problem calculus based on a viewofrequirementsengineeringproposedbyZaveandJackson, thatwehope can underpin techniques and processes in requirements engi-neering and early software design. The approach is centred aroundthe notion of problem and problem transformation. It is proposi-tional in nature in that it allows for heterogeneous problem descrip-tions and correctness argumentation for the validation and verifica-tion of solutions. We present a number of fundamental rules topopulate the calculus including ‘divide-and-conquer’ problem de-composition, description reification, prior-solution reuse, the use of architectures for solution structuring. In addition, and central to thefoundational nature of the calculus is the interpretation and subse-quent incorporation into our framework of others’ work as problemtransformations. This is an on-going task: examples presented inthis paper include interpretations of simple goal-oriented decompo-sitions and viewpoints. The calculus also provides rich traceabilityof the requirements of an srcinal problem through transformationto those of its solution. We use the design of a sluice gate as asimple running example throughout the paper. 1. INTRODUCTION The purpose of this paper is to define a calculus for requirementsengineering based on the notion of software problem and softwareproblem transformation. Software problems take many forms. Forus a software problem is a contextualised need that has a softwaresolution. This takes its inspiration from Jackson’s work on ProblemFrames (PF) [21], although its tradition goes back to, at least, Polya[29].Our software problem calculus embodies the standards for re-quirements engineering established in The Four Dark Corners pa-per of Zave and Jackson [42]. These standards, quoted or para-phrased in italics below, are based on the separation of the machine, i.e., the computational artefact, and the environment for which themachine is to be built, expressed as: •  The terminology used in requirements engineering should be grounded in the reality of the environment for which amachine is to be built.  Our calculus allows for description Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.Copyright 200X ACM XXXXXXXXX/XX/XX ... $ 5.00. grounded in the language of the domain — in particular, itdoes not prescribe a single description language in whichdesignationsareexpressed. Inthissenseourcalculusispropo-sitional in nature: it operates above the language of the do-main. •  It is not necessary or desirable to describe (however ab-stractly) the machine to be built. Rather, the environment is described in two ways: as it would be without or in spiteof the machine (the indicative mood), and as we hope it willbecomebecauseofthemachine(theoptativemood).  Ourcal-culus similarly separates indicative and optative descriptions,so that we focus on the requirements and domains rather thanthe solution. •  It is essential to identify which phenomena are controlled bythe environment, which phenomena are controlled by the ma-chine, which phenomena of the environment are shared withthe machine, and which phenomena are constrained or re- ferred to by the requirement.  This separation is an impor-tant part of our calculus: a solution machine must correctlycontrol and observe the phenomena that its environment ex-poses; our calculus assumes that each phenomena has a sin-gle controller (either in the environment or the machine); theaim of the machine is to satisfy the constraints expressed inthe requirements. •  The primary role of domain knowledge in requirements en-gineering is in supporting refinement of requirements to im- plementable specifications. Correct specifications, in con- junction with appropriate domain knowledge, imply the sat-isfaction of the requirements.  Our calculus provides prob-lem transformations for requirements refinement in order tobridge the gap to implementable specifications.Our calculus takes a proof-theoretic form, as is found in the work of Gentzen [22, 28], in using semantics preserving transformationson sequents, a sequent being a problem statement, i.e., a syntacticcharacterisation of a problem. Manipulation of problems, i.e., therelation of problems to problems, occurs through the applicationof rules in the calculus. Rules are defined to relate problems-with-solutions to problems-with-solutions by relating their components,i.e., their context, requirement, and solution form. In addition, inparallel with the development of a solution of a problem, a correct-ness argument is created that justifies its solutionhood.The paper is structured as follows... 2. RELATED WORK Acalculusforrequirementsengineeringtothebestofourknowl-edge is missing from the literature. However, a reference model for  requirements and specifications which shares the Four Dark Cor-ners’ foundations with this work was defined in [14], and extendedby Hall and Rapanotti in [15]. The focus of the reference modelis the formal characterisation of the meaning of requirements andspecifications and their relationship as well as what it means forrequirements engineering to be complete. Instead our calculus pro-vides a framework for the refinement of requirements into speci-fications. The notion of software problem is not included in thereference model, while it is the focus of our calculus. Based on thereference model, REVEAL [17] is a process for requirements engi-neering based on the disciplined use and separation of domain, re-quirementsandspecificationsdescriptionsandthedischargeof cor-rectness arguments for validation and rich traceability of require-ments. In being based on the reference model, REVEAL has noexplicit notion of problem and problem transformation, althoughit is possible to give an interpretation of some of its process stepsas problem transformations within our framework. Being rooted inpractice, REVEAL has provided extensive validation of the refer-ence model for practical industrial requirements engineering.Problems-oriented requirements engineering was proposed byJackson in his Problem Frames approach, [20, 21]. (A roadmap of Problem Frame-related research appears in [9].) Problem Framesappear similarly motivated by [42] and provide a graphical nota-tion for representing and classifying software problems. They alsoidentify two basic types of problem transformatons, projection andprogression. They do not, however, formally characterise problemsnot do they formally relate problems one to another as we do inour calculus. In the paper, we will discuss how problem frames areproperly captured in our calculus.Formal characterisation of problems have appeared as proposedsemantics of Problem Frames. Hall  et al . forge a formal relation-ship between Problem Frames and the reference model in [16].Work by Bjorner ([3]) characterises the properties of some earlyproblem frames in terms of typical types of domains and require-ments, and for two of them, the design of the solution machine.[5] takes this approach further, providing a formalisation of theTranslation frame and Information System frame using CASL (theCommon Algebraic Specification Language, [7]). [10] proposesa semantic approach which uses UML as a means of describing ameta-model as a semantics for problem frames that might be usedto insert a notion of problem into the UML. The meta-model de-scribes context diagrams, problem diagrams and problem frames,but does not capture the meaning of other elements, such as correct-ness of a machine specification with respect to its environment andrequirements. None of these approaches to a semantics of problemframes address the formal relation between problems or the formalrefinement of requirements into specifications.Parallel to problem-based approaches, a range of goal-orientedapproaches to requirements engineering have been proposed whichare based on the notions of goal, task and agent. Transformationsare then goal refinements and decompositions as well as the assign-ment of a task to agents to satisfy goals. Goal-based and problem-based approaches can be seen as complementary, as demonstrated,for instance, by the work of Bleistein et al, [4] on combining i* [41,40] and Problem Frames. As we will see, in our calculus goal de-composition can be captured as a type of requirement refinement,under the interpretation of goals as requirements.Parallel to problem-based approaches are the scenario-based ap-proach to requirements engineering, such as Volere [31] and Use-cases [6]. These are usually predicated on the identification of business processes within an oganisation, which need some formof automation. Relevant business rules that governs such processesneed be identified together with their boundary, the external busi-ness events to which they react, and the effect of such events. Sce-narios are then used to identify the technical requirements that theautomated system should satisfy. In such approached the notion of problem is missing, and they tend to be informal to a large extent.However, by interpreting business processes and their boundary asa problem context, scenario-based techniques for refining require-ments can be seen as a form of problem progression - one of theidentified types of problem transformation in our framework. 3. PROBLEMS, SOLUTIONS For us, a software problem is a requirement in a real-world con-text. The context is a collection of interacting domains, describedby their indicative properties; the requirement is an optative prop-erty that we would like to be true of the context.Fortherequirement R  andreal-worldcontext W   =  { D  1 , ..., Dn  } eachdomaininthecontextwillexposevariousphenomena—events,commands, states, entities,  etc . — that it controls and which can beobserved by another domain in the context; the domain will also beable to observe exposed phenomena from other domains in the con-text. In addition, the domain may have internal phenomena which,although unobservable to other domains, can be constrained or re-ferred to in the requirement. That  D   controls the phenomena set c  , observes the phenomena set  o , and has internal state  d   will bewritten 1 D  ( d  ) co . There are simple correctness conditions on thesesets,  viz. : they should be pairwise disjoint. That the requirement  R constrains phenomena set  c   and refers to phenomena set  r   is writ-ten  R cr  , again  c   and  r   should be disjoint. A phenomenon has pre-cisely one controller. A phenomenon is said to be  machine share-able  when it can be either controlled or observed by a machine; forinstance, the temperature of a room is not machine shareable, theoutput of a temperature sensor could be machine shareable.The control-observes links between domains provide a softwareproblem with a topology: domains D  c and E  o  are linked if  c  ∩ o   = ∅ . Similarly, the requirement can be incorporated into the topologyif, with domain  D  ( d  ) co , it constrains or refers to a phenomenon in d  ∪ c  ∪ o . The linking of domains imbues the context with controlsand observes sets: for the  W   =  { D  1 , ..., Dn  }  above,  W  co  when Di  c i  o i  , and  c   (respectively  o ) are the machine shareable phenomenain S c  i   (respectively S o i  ).A software problem challenges us to find a solution that, in thecontext, brings about the requirement. Typically, a machine will beable to observe or control a proper subset of those phenomena ex-posed by a problem’s context, i.e., the machine shareable phenom-ena. The machine must observe and control the context throughthese phenomena, so to have it satisfy the requirement, i.e., solvethe software problem.Formally, for  W  co  =  { D  1 , ..., Dn  } , a  pre-solution  S   to a soft-ware problem must fit within the problem context, i.e.,  S  oc  . In ourcalculus, that S   is a pre-solution to a software problem with context W   and requirement  R  is indicated by writing (the sequent): W  , S   R (To be able to distinguish the pre-solution, it will always be writtenclosest to the    symbol, on the left.) As already mentioned, se-quents are syntactic expressions, manipulated by rule application.A pre-solution is a  solution  to a software problem if it is accom-panied by a correctness argument  CA  which justifies, to an appro-priate level of conviction, its solution status. There are many levelsof conviction to which a correctness argument may be justified; weturn to the literature and practice for some examples: if (almost) ab- 1 We will often omit a superscript or subscripted if these are clearby context, or if we are not concerned with them.  solute conviction is required we could require a fully formal proof of solutionhood; many projects work to a level of conviction pro-vided by testing; another is the development of safety cases thatsatisfy a safety authority; perhaps the weakest is simple trust. Itis important to note, therefore, that the correctness argument is notnecessarily a statement requiring formal proof of correctness: itsrole is to justify a solution, not to remove doubt.Acorrectnessargumentdistinguishesapre-solution—i.e., some-thing that interacts with a problem context in the correct way, butperhaps not able to achieve the requirement — from a solution. Assuch it is a very important component of our framework. Later inthis paper we will show how a correctness argument for a particularsolution can be defined incrementally through problem transforma-tion.Although a slight abuse of notation, it will be convenient to beable to refer to the triple  W  , S   R  as a problem. 3.1 Example As an example, we consider the software problem of designing asluice gate controller, based on [21, 23]. Finding a solution to thisproblem will be a goal of this paper; it will also illustrate some of the aspects and properties of our software problem calculus. Theproblem is simple, but not so simple as to be trivial as we shall see.The reader should imagine a customer in the market for a sluicegate controller, from whom the requirements engineer is gatheringrequirements.From the literature, we know that the relationship between cus-tomer and requirements engineer is based on communication butthat this communication is not always smooth — it will sometimesbe the case that misunderstandings can occur because of no sharedlanguage, because of unwritten assumptions by either side,  etc , sothat iteration between the parties is needed to gain clarification. Tous, this is all part of the problem solving process, and so should notbe ignored by the calculus; the example will give a flavour of howthis is handled.The given domain descriptions for this problem, those that to-gether form  W   are: G  The Gate, when stopped, reacts to (i.e., observes) a   Clockw  , On   eventsequencebymovingupwards, unlessalreadyfullyopen. Whenstopped, itreactsto(observes)an  AntiClW  , On   event sequence by moving downwards, unless already fullyclosed. When it receives (observes) an  Off   event it turns itsmotor off, stopping any motion. When it detects that it isfully open it generates a  Top  event (that it controls). Whenit detects that it is fully closed it generates a  Bottom   event(that it similarly controls). Op  The operator generates (controls)  Raise   commands to requestthat the gate moves upwards, generates (controls)  Lower  commands to request that the gate move downwards, andgenerates (controls)  Stop  commands to request that the gatestops.From the description, the phenomena are 2 a   :  { Raise  , Lower  , Stop }  b  :  { Top , Bottom  } c   :  { ClockW  , AntiClW  , On  , Off  }  d   :  { Open  , Shut  } with  a   controlled by the operator,  b  (respectively,  c  ,  d  ) controlledby (respectively, observed by, an internal state of) the gate.We will assume that the initial requirement description for gateoperation as gathered from our customer consists of two statements TGO and MGO , apparently intended as a conjunction: 2 The phenomena are presented as named sets, which facilitatestheir repeated reference. TGO  The gate should be  Open   only for the first ten minutes of each three-hour period. MGO  The gate should be either  Open   or  Closed   consistent withthe Operator’s commands to  Raise  ,  Stop  or  Lower  .Taken as a simple conjunction,  TGO  and  MGO  sometimesconflict and so are not always satisfiable: consider what shouldhappen during the first ten minutes of a three-hour period, if theoperatorcommandsthegateto Lower  . Ourfirsttaskinthecalculuswill be to clarify what the customer means.With pre-solution C , even if unsatisfiable, we may represent thissoftware problem as: G ( d  ) bc , Op a  ∅ , C ca  , b    ( TGO and  MGO ) d a  4. PROBLEM TRANSFORMATION It is often the case that by solving one problem we are led to thesolutionofanother. Therearemanyexamples: frommathematics, asolution to Fermat’s equation — that of the famous last theorem —leads to a contraction with the Taniyama-Shimura conjecture [33];from software engineering, software problems are split up underfunctional decomposition, object-orientation,  etc  to be able to solvethem; in addition, solving a software problem in a test harness oftenleads (perhaps not directly) to a solution in the real-world.There are many benefits of transforming one problem into an-other: •  one may be easier to solve; it may be stated in a way thatmakes it more amenable to solution; •  one may already have been solved; •  one may be more detailed, specific and/or correct; •  there may be specialists who know how to solve the trans-formed problem; •  etc .A problem transformation should, to be useful, be accompanied bytwo related artefacts: •  a transformation that relates the solutions of the transformedproblem (if and when found) to that of the srcinal — in thecase of a test harness, it may be that the same solution may beused in the final environment, most likely with extra testing; •  an argument that justifies the transformation as correct —we should be convinced that correctness of the solution inthe transformed problem leads to a correctness of the trans-formed solution in the srcinal problem.Rules in our calculus transform problem to problems, and in-clude each of these artefacts. Formally, a rule in our calculus is aninstance and/or specialisation of the following rule. Suppose wehave problems  W  , S     R ,  Wi  , Si     Ri  ,  i   = 1 , ..., n  , then wewill write W  1 , S  1    R 1  ...  Wn  , Sn     Rn W  , S     R  CA to mean that, if  CA holds then  S   is a solution of   W  , S     R  when-ever  S  1 , ..., Sn   are solutions of   W  1 , S  1    R 1 , ..., Wn  , Sn    Rn  , respectively. Typically,  CA  will contain a clause that relatesthe form of the solution  S   to the srcinal problem to those of thetransformed problems  S  1 , ..., Sn   — this is the relation of solu-tion of the transformed problems to the solution of the srcinal.  Similarly, there will be similar clauses relating context and require-ments.The remainder of  CA is used to justify the transformation is cor-rect; i.e.,  CA  is a step in a correctness argument for the solution,specifically, CA extends the transformed problems’ correctness ar-guments to be that of the srcinal problem. 5. CLASSESOFPROBLEMTRANSFORMA-TION In this section, we propose a number of classes of problem trans-formation. Theseare, variously, encodings, extensionsandgeneral-isations of problem transformations found in the literature, as wellas simpler and more complex transformations that we identify andintroduce in this paper.In our example, the first step we will take is to clarify how theconflicting statements MGO and TGO should form a satisfiablecustomer requirement. We do this by applying the Domain andRequirement description reification rule: 5.1 DomainandRequirementdescriptionreifi-cation A rich source of transformation is the reification of domain de-scriptions, i.e., taking an initial less precise description — naturallanguage say — as captured from the customer, and re-expressingit more precisely — as a statechart description of a real-world do-main, say. This is the domain modelling step. As the needs of development change, as we approach a solution through problemtransformation, natural language changes into other, more precise,descriptions.Formally, domainandrequirementsdescriptionreificationiscap-tured by the following rule: W  , D   , S     R  W  , D  , S     RD   more precise than  D  and   R  more precise than  R in which W   stands for the parts of the context other than the reifieddomainThe reader will note that the correctness argument is not ex-pressed formally. Although a more formal expression might be ap-propriate in a particular development environment — if Z [ ? ] wasbeing used as the development language, for instance — it wouldbe a mistake to be too prescriptive about the level of convictionneeded in the rules expression as we want to be able to allow bothformal and informal forms of description reification. 5.1.1 Example In consultation with the customer, we have been able to clarifythat that operator should be able to override the timed gate oper-ation, i.e., the customer intended TGO  unless  MGO . As a re-quirement reification, this can be recorded as: G ( d  ) bc , Op a  ∅ , C ca  , b    ( TGO unless MGO ) d a  G ( d  ) bc , Op a  ∅ , C ca  , b    ( TGO and  MGO ) d a  Customer intent  (where  Customer intent   indicates that  unless  is the customer’s in-tendedmeaningfor and  ). Inthesequel, wewillreferto TGO unless MGO as GO . 5.2 Problem Projection Underproblemprojection, anumberofsub-problemsareformed,each of which is intended to solve some small part of the srcinalproblem. Problem projection is described as: W  1 , S  1    R 1  ...  Wn  , Sn     Rn W  , C ( S  1 , ..., Sn  )    R 1 ∧ ... ∧ Rn R 1 , ..., Rn   not in conflict and  C a linearizablecombinator  where S Wi   =  W  . That  C  is a linearizable combinator meansthat it places the  Si   in parallel and ensures that their combinedeffect is linearizable [18]; specifically, it ensures there is no de-structive interference between the sub-problem solutions; see forinstance [21] for a discussion. When the  Si   do not interfere,  C can be simple parallel composition. Problem projection includes— indeed, was inspired by — the notion of problem projection of Problem Frames as defined in [21].It is worth restating that, although the correctness argument maybe capable of formal discharge — that  R 1 ∧ ... ∧ Rn   is never falsecan be proven by considering its truth value at each time point —for instance, there is no requirement in our calculus to do so. Of course, without a formal proof, there will be no certainty that therule produces a correct transformation, but this matches the casein software engineering: without proof, one cannot know a pieceof software is correct, but most software cannot be proven correct,and yet is still written. 5.2.1 Example Consider again the gate problem: as TGO and MGO sometimesconflict, theydonotallowproblemprojectiontobeapplieddirectly.However, writing  R 1  as “ TGO when no operator command” and R 2  as “ MGO ” then  GO  ⇐⇒  R 1  ∧  R 2  so that the problemprojection rule may be applied leading to G ( d  ) bc , Op a  ∅ , C1 ca  , b    R 1 d a  G ( d  ) bc , Op a  ∅ , C2 cb    R 2 d a  G ( d  ) bc , Op a  ∅ , C ( C1 , C2 ) ca  , b   GO d a  R 1 , R 2  not in conflict and  C a linearizablecombinator  for some linearizable combinator C , not specifically determined bythis rule. Indeed, there are many forms that C can take; we will useone of them to illustrate the use of architectures in the calculus. 5.3 Architectural expansion The approach upon which our calculus is based emphasise thedistinction between environment and system spaces, i.e., betweenthe problem and solution domains. Other approaches, such as theProblem Frames approach, intend their user to focus their attentionon the problem space, practically ignoring the solution space untilthe problem is wholly understood. While undeniably a useful sep-aration of concerns for requirements engineering, we feel that thisseparation should not be interpreted to mean that a software devel-opment is a linear process from problem to solution: first require-ments engineering, then software development as there are manycharacteristics of modern software engineering practice that wouldcontradict this. Firstly, even modestly complex problems can forceproblem owner and solution engineer into negotiation over trade-offs and consideration of details of the solution [1]. Secondly, inpractice, the development of new systems is very rarely green-field:new software is usually developed from existing components [19]or within existing frameworks [11] and architectures [32]. Finally,expertworkersinwell-knownapplicationdomainsexpresstheirex-pertise through development, even for bespoke software. Thereforeour calculus includes problem transformations which allow solu-tion space knowledge to be used to inform the problem analysis fornew software developments.An architecture is assumed to combine a number of extant com-ponents and components yet to be found in a topology. An ar-
Search
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks