The Dependency-Guarantee Model Dependency-Guarantee Relationships (DGRs) • Exists to support the Safety Argument • Organises (and refines) information from the “Design” domain. • Capture the critical guaranteed behaviour of the software components. • Define the behaviour on which the software component is dependent in order to uphold its guarantee. • A process used for producing them is documented in IAWG-AJT-301 section 14.3 (Hawk OSL). • Dependency-Guarantee Contracts (DGCs) • Exist to support the Safety Argument • Capture the integration of software components, the mapping of a dependency to a guarantee that satisfies it. 18/04/07

DGRs: Dependency and Guarantee Identification • Analyse and Organise the Lifecycle Data • Requirements can be manually analysed. • Spark information flow notations on the code can be analysed. • Test Information can used. • Etc. • Derive a Minimal Guarantees Set • Must be relevant to the criticality of the system. • Only the principle behaviour should be captured. • Derive a Maximal Dependency Set • The set of information analysed in the search for dependencies should provide sufficient confidence that all dependencies have been identified. • Organise Optimally for the Integrator • The DGRs are information published by a module developer to the integrator to facilitate integration. 18/04/07

DGR Process 1: DGRs from Requirements Specifications ORGANISING THE WORK • Split the source material up into manageable groups. Define the PRIMITIVES. Each primitive is a candidate for a DGR. (continued) The quality and depth of requirements is quite variable from one project to another. • Each PRIMITIVE should have a single purpose, a single guarantee. If there is a corresponding IFS that can be useful. • PRIMITIVES should be reasonably independent, or is it a good design? • Do sneak a peak at the design and IFS to get guidance if necessary. • Choose PRIMITIVES that are as large as you can handle. 18/04/07

DGR Process 2: DGRs from Requirements Specifications ORGANISING THE WORK (continued) • Group the primitives into modules. (continued) Choice of DGR modules is different from the choice of safety argument modules. (Several DGR modules may be utilised by the same safety argument). Choose a DGR module for each software component. The configuration of DGR modules may be altered in the same way as the configuration of the system. Again, Do sneak a peak at the design or other material to get guidance if necessary. 18/04/07

DGR Process 3: DGRs from Requirements Specifications ORGANISING THE WORK (continued) • Identify the primitives whose behaviour is effective at the module boundary. (The external primitives) • Identify any hierarchy of primitives within the module. (continued) The external primitives may principally be the ones that correspond to the module services. 18/04/07

DGR Process 4: Choice of Primitives • Each primitive is just a group of requirements. 18/04/07

DGR Process 5: DGRs from Requirements Specifications (continued) DOING THE WORK • Create DGR tables for the external primitives • Create DGR tables for the subordinate primitives (continued) See hints/tips on slides 12-17. 18/04/07

Creating DGR Tables 1: DGR Template Issue 1 18/04/07

Creating DGR Tables 1: Presentation Notes on DGR Template Issue 1 [1] The parameters provide a means of semi-formally identifying the information flows in/out of the primitive(s). Guarantees and Dependencies are expressed with reference to these information flows. [2] The transaction partner actual name will not be known, use keyword “consumer” or “producer”. [3] This is the english text description that will be used to satisfy a dependency. The requirement will be of the form something “shall” be done, the quarantee should state something “is” done. The formal postcondition from the code domain may be specified here (if the DGR is that detailed)? [4] This is a description of the values of any ‘control’ information that is passed out of the module when the guarantee is met. e.g. a returned status. [5] This is the description of the dependency from the source material domain in english text (with reference to parameters). [6] Can the absence or failure of the dependency be detected at run-time? [7] This is the postcondition if the dependency is detected as absent at run-time. [8] This is the information available for the formation of a contract to satisfy the dependency. It is called Detection/Analysis for historical reasons. 18/04/07

Creating DGR Tables 2: Deriving the Guarantee • The Guarantee • Worded to assume the dependencies. • It needs to be a guarantee that is useful to the argument. • Concise • But are all terms well defined? (e.g. “virtual channel”) • Atomic. • Could there be multiple DGRs here? • Normal behaviour only. • Guarantees to detect or handle errors are dealt with elsewhere. • Guarantees can be supplied • As a result of service calls • As a result of events being serviced • Upheld at all times. 18/04/07

Creating DGR Tables 3: Different Sources of Dependency • Internal Dependencies • A temporary measure prior to aggregation OR • Provided with a corresponing DGC. • Dependencies on the Content of Supplied Information • Including from or through the consumer (preconditions) • Dependencies on Shared Resources • Is an existing system issue. • Hardware Dependencies • On the boundary of Mod Cert scope of work, retricted to MSL. • Ubiquitous dependency on the correct operation of the processor. • Validation Rule Dependency • Test evidence will not uphold the G at the same level of confidence throughout all possible uses. • Behavioural Dependencies • See later slide • Dependencies on Internal State of the Module • See later slide 18/04/07

Creating DGR Tables 4: Validation Rule Dependencies This slide illustrates the thought process that might go on behind definition of a validation rule dependency. Working at a well defined “single” level of confidence, what are the restrictions on the scope of the evidence set supporting the guarantee? 18/04/07

Creating DGR Tables 5: Behavioural Dependencies • D1: The successful transmission of a request to module B • D2: The successful reception of an acknowledgement from module B • D3: The behaviour of module B, specifically that in response to the reception of a request module B will send an acknowledge. 18/04/07

Creating DGR Tables 6: Dependencies on Internal State • Common dilemma, but not one restricted to the DGR model. • Some Examples. In order to uphold the Guarantee… • Some data in the Module must have been previously initialised. • Some data in the module must have been calculated from various inputs. • The module must be in an appropriate state. • These dependencies can be written temporarily as is and then refined later. • The developer should decide what is the minimal set of information about the module’s internal state that he wishes to publish to its users and the DGRs should also stick to it. 18/04/07

Creating DGR Tables 7: Dependencies on Internal State Example Mode Diagram The developer has decided that the minimal set of information about the module’s internal state that he wishes to publish to its users is a mode diagram. The DGRs may also refer to it. 18/04/07

DGR Process 6: DGRs from Requirements Specifications DOING THE WORK (continued) • Either • Aggregate the subordinate DGR tables into the external DGR tables to create the final DGRs. • This is an increasingly formal way of merging subordinate DGRs into their parents. • Or • Form DGCs to link them. • If the DGRs need to remain separate, e.g. if a service uses a sibling service. Aggregation is used to assist with the creation of DGRs for groups of source material that are too big to be handled as a single primitive. See 5 following slides that animate aggregation. 18/04/07

DGR Aggregation 1 18/04/07

DGR Aggregation 7 Review the new dependencies • remove duplication • ensure correct use of parameters 18/04/07

Summary of Presentation • What is a DGRs (or DGCs)? • How to create DGRs (from Requirements) • How to organising the work • Primitives and DGR Modules • How to deal with commonly encountered issues • Internal Dependencies • Dependencies on the Content of Supplied Information • Dependencies on Shared Resources • Hardware Dependencies • Validation Rule Dependency • Behavioural Dependencies • Dependencies on Internal State of the Module • What is Aggregation? • When to use it. 18/04/07

Contents

Contents

Presentation Transcript

Contents

Contents

Contents

Contents

Contents

Contents

Contents

CONTENTS

Contents

Contents