Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Towards a methodology for rigorous development of generic requirements patterns.

Slides:



Advertisements
Similar presentations
Andrea Maurino Web Service Design Methodology Batini, De Paoli, Maurino, Grega, Comerio WP2-WP3 Roma 24/11/2005.
Advertisements

Integration of MBSE and Virtual Engineering for Detailed Design
User Driven Modelling and Systematic Interaction for End-User Programming Modelling for Engineering Processes Peter Hale UWE.
Translation-Based Compositional Reasoning for Software Systems Fei Xie and James C. Browne Robert P. Kurshan Cadence Design Systems.
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
© Colin Potts C6-1 Some future trends in requirements engineering Colin Potts Georgia Tech.
25 February 2009Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department.
Specification, Partitioning, and Composition Techniques for Web Applications in the Context of Event-B Abdolbaghi Rezazadeh Michael Butler University of.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Software Processes Coherent sets of activities for specifying, designing, implementing and testing software systems.
Dagstuhl Intro Mike Whalen. 2 Mike Whalen My main goal is to reduce software verification and validation (V&V) cost and increasing.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development.
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
The Architecture Design Process
July 2005REFT workshop, Newcastle1 Some thoughts about product line engineering: using UML, B, and refinement - emerging from CS2/ATEC A research programme.
Automated V&V for High Integrity Systems A Targeted Formal Methods Approach Simon Burton Research Associate Rolls-Royce University Technology Centre University.
CS 425/625 Software Engineering Software Processes
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
Development Processes and Product Planning
Department of Computer Science & Engineering College of Engineering Dr. Betty H.C. Cheng, Laura A. Campbell, Sascha Konrad The demand for distributed real-time.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 10 Slide 1 Formal Specification.
6 Feb 08 Deploying Rodin Michael Butler Dependable Systems and Software Engineering University of Southampton.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Chapter 10: Architectural Design
Software Architecture. Agenda " Why architect? " What is architecture? " What does an architect do? " What principles guide the process of architecting?
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 10 Slide 1 Critical Systems Specification 3 Formal Specification.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 10 Slide 1 Formal Specification.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
Transitioning From Software Requirements Models to Design Models
The Design Discipline.
Managing Software Quality
CSI315 Web Applications and Technology Overview of Systems Development (342)
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
Software Processes Sumber dari : cc.ee.ntu.edu.tw/~farn/courses/SE/ch4.ppt.
An Introduction to Software Architecture
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Software Processes lecture 8. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
CSE 219 Computer Science III Program Design Principles.
WXGE6103 Software Engineering Process and Practice Formal Specification.
Approaching a Problem Where do we start? How do we proceed?
1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.
OHTO -99 SOFTWARE ENGINEERING “SOFTWARE PRODUCT QUALITY” Today: - Software quality - Quality Components - ”Good” software properties.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Object-Oriented Software Engineering using Java, Patterns &UML. Presented by: E.S. Mbokane Department of System Development Faculty of ICT Tshwane University.
1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2.
RE-ENGINEERING AND DOMAIN ANALYSIS BY- NISHANTH TIRUVAIPATI.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Design CS 470 – Software Engineering I Sheldon X. Liang, PH.D.
PROGRAMMING FUNDAMENTALS INTRODUCTION TO PROGRAMMING. Computer Programming Concepts. Flowchart. Structured Programming Design. Implementation Documentation.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
A Method for Improving Code Reuse System Prasanthi.S.
Formal Specification.
ITEC 370 Lecture 13 Design.
SysML 2.0 Formalism Requirements and Potential Language Architectures
Object-Oriented Software Engineering Using UML, Patterns, and Java,
Component Based Software Engineering
Software Processes.
Need for the subject.
An Introduction to Software Architecture
Luca Simoncini PDCC, Pisa and University of Pisa, Pisa, Italy
Presentation transcript:

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Towards a methodology for rigorous development of generic requirements patterns Colin Snook, Mike Poppleton - University of Southampton Ian Johnson - AT Engine Controls (ATEC)

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Background Rodin project - Case study Fault tolerant systems + rigorous methods Failure Management Subsystem of aircraft engine control Re-use at specification level (formal v & v) Re-use within project - Domain specific language Product line engineering - produce variants Tools at University of Southampton: UML-B = UML profile for formal UML (based in B) U2B = translates UML-B into B ProB= animator and model checker for B

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Failure Management

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Overview of Process instantiate generic model verify instantiation specific application requirements specific model consistent specific model domain analysis domain engineering first-cut generic model validated generic model previous product experience for each new application once for the domain

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Domain Analysis instantiate generic model verify instantiation specific application requirements specific model consistent specific model domain analysis domain engineering first-cut generic model validated generic model previous product experience for each new application once for the domain

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Domain Analysis Identify common requirements * Taxonomy for domain Requirement rationale (the why) Justify reasoning behind requirement decisions Relationships between elements A first-cut model of the domain Nat.lang. generic spec. (semi-rigorous style) rationale – explanation precise statement of requirement * Lam: Achieving Requirements Reuse: A Domain- specific Approach from Avionics, J.Systems Software :

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Some Typical Requirements Value testedHigh limit Low limit Rate limitConditions for test ESa* 120%0%100%/secEngine Stood 120%10%100%/secEngine Starting 120%50%100%/secEngine Running ESb* 120%0%100%/secEngine Stood 120%10%100%/secEngine Starting 120%50%100%/secEngine Running ESa – ESb5%-5%-ESa >30% or ESb >30% Table 2. Remedial Actions Value failedProcedureCode ESaSelect ESb if availableES1 otherwise switch to backup system ESbSelect ESa if availableES2 ESa - ESbUse highest of ESa and ESbES3 Table 1. Failure Detection *ESa – Engine speed (main input), ESb – Engine speed (alternative input)

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Taxonomy of requirements INP input (to the failure management subsystem) CONDcondition for a test DETfailure detection mechanism CONFconfirmation of suspected failure ACTan action taken OUToutput (from the failure management subsystem)

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 First-cut model in UML UML class diagram representation of relationships between kinds of functional requirements

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Example of format Rationale: The subsystem needs to be tolerant to isolated errors, which may be transient, so as to maintain stability in the control system. In order to achieve this, a failure confirmation mechanism is employed to confirm when a firm fault has been established. CONF2 A sensor input will have been determined to have failed, only if a failure confirmation mechanism has confirmed it.

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Instantiation of spec.

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Domain Engineering instantiate generic model verify instantiation specific application requirements specific model consistent specific model domain analysis domain engineering first-cut generic model validated generic model previous product experience for each new application once for the domain

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Model revised for U2B

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Validating generic model

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Validated generic model

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Defining a specific application instantiate generic model verify instantiation specific application requirements specific model consistent specific model domain analysis domain engineering first-cut generic model validated generic model previous product experience for each new application once for the domain

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Instance model

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Verifying the specific model instantiate generic model verify instantiation specific application requirements specific model consistent specific model domain analysis domain engineering first-cut generic model validated generic model previous product experience for each new application once for the domain

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Verifying specific application says which law is broken but not who broke it

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Future Work Behaviour validate specific application need behaviour to animate with ProB behaviour should be in generic model Thoughts: …behaviour should come via abstraction …rationale (key issues)  abstract reqmts. …refine and verify in generic model

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Adding verification of rationale instantiate generic model domain analysisdomain engineering first-cut generic model validated generic model (with behaviour) previous product experience for each new application once for the domain verify key issues generic model (verified) requirements rationale abstract generic model abstract domain engineering

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Validation of Specific model instantiate generic model verify instantiation specific application requirements specific model consistent specific model generic model (verified) for each new application validate instantiation validated specific model

Engine Controls Rodin EU project IST REFT’05 – Newcastle, July 2005 Summary RE process for generic domains (early stages of) rigorous but friendly close mapping to problem domain re-usable components… (DSL for RE) product line method for complex domains Current Tools UML-B enables visualisation of models ProB animation - validation of generic model ProB model checker - verification of specific but could be difficult to find offending data Future work Add behaviour Provide tool support for instantiation phase