Friday, April 17, 2015 Requirements Specifications Interaction Analysis Bill Mitchell Software and Systems Research Labs Motorola UK Research Labs Bill.

Slides:



Advertisements
Similar presentations
SYNTHESIS: a tool for automatically assembling correct and distributed component-based systems Massimo Tivoli Computer Science Department University of.
Advertisements

System and Software Engineering Research 1 Motorola 2003 Integrated Application of MSC Clive Jervis Rapporteur Q15 Motorola UK Research Labs.
Test process essentials Riitta Viitamäki,
Seyedehmehrnaz Mireslami, Mohammad Moshirpour, Behrouz H. Far Department of Electrical and Computer Engineering University of Calgary, Canada {smiresla,
A Survey of Runtime Verification Jonathan Amir 2004.
4b Lexical analysis Finite Automata
ES Seminar1 Communicating Transaction Processes P.S. Thiagarajan National University of Singapore Joint Work with: Abhik Roychoudhury; ……
1 Model checking. 2 And now... the system How do we model a reactive system with an automaton ? It is convenient to model systems with Transition systems.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
M INERVA (Metamodel-based Intuitive Editors with Reports and Visualizations of Analysis) Laura A. Campbell Advisor: Dr. Betty H.C. Cheng Software Engineering.
Presented by: Thabet Kacem Spring Outline Contributions Introduction Proposed Approach Related Work Reconception of ADLs XTEAM Tool Chain Discussion.
ISBN Chapter 3 Describing Syntax and Semantics.
1 Spin Model Checker Samaneh Navabpour Electrical and Computer Engineering Department University of Waterloo SE-464 Summer 2011.
Automated creation of verification models for C-programs Yury Yusupov Saint-Petersburg State Polytechnic University The Second Spring Young Researchers.
Formal Software Testing and Model Checking Generating Test Cases For a Timed I/O Automaton Model Leonid Mokrushin.
Software Testing and Quality Assurance
28/6/05 ICFI05 1 A generic approach for the automatic verification of featured, parameterised systems Alice Miller and Muffy Calder University of Glasgow.
© Betty HC Cheng. This presentation is available free for non-commercial use with attribution under a creative commons license. Acknowledge: S.
Validating Streaming XML Documents Luc Segoufin & Victor Vianu Presented by Harel Paz.
Slide 1 MSC and SDL. Slide 2 Relationship of MSC to SDL An MSC describes one or more traces of an SDL system specification. An entity in MSC may map to.
Specification Formalisms Book: Chapter 5. Properties of formalisms Formal. Unique interpretation. Intuitive. Simple to understand (visual). Succinct.
1 Ivan Lanese Computer Science Department University of Bologna Italy Concurrent and located synchronizations in π-calculus.
Presenter: PCLee Design Automation Conference, ASP-DAC '07. Asia and South Pacific.
PZ02B Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, PZ02B - Regular grammars Programming Language Design.
University of Toronto Department of Computer Science © Steve Easterbrook. This presentation is available free for non-commercial use with attribution.
Implementing Remote Procedure Calls an introduction to the fundamentals of RPCs, made during the advent of the technology. what is an RPC? what different.
Describing Syntax and Semantics
DISTRIBUTED PROCESS IMPLEMENTAION BHAVIN KANSARA.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 10 Slide 1 Critical Systems Specification 3 Formal Specification.
SOFTWARE ENGINEERING BIT-8 APRIL, 16,2008 Introduction to UML.
Finite-State Machines with No Output Longin Jan Latecki Temple University Based on Slides by Elsa L Gunter, NJIT, and by Costas Busch Costas Busch.
Finite-State Machines with No Output
Parser-Driven Games Tool programming © Allan C. Milne Abertay University v
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Scientific Computing By: Fatima Hallak To: Dr. Guy Tel-Zur.
SOFTWARE DESIGN.
WXGE6103 Software Engineering Process and Practice Formal Specification.
Lecture 05: Theory of Automata:08 Kleene’s Theorem and NFA.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: LTL Model Checking Copyright , Matt Dwyer, John Hatcliff,
Timed Test Cases Generation Based on MSC-2000 Test Purposes Abdeslam En-Nouaary and Gang Liu Department of Electrical and Computer Engineering Concordia.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
Paper written by Flavio Oquendo Presented by Ernesto Medina.
Scenario Synthesis from Imprecise Requirements Bill Mitchell, Robert Thomson, Paul Bristow.
1 Qualitative Reasoning of Distributed Object Design Nima Kaveh & Wolfgang Emmerich Software Systems Engineering Dept. Computer Science University College.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
The Software Development Process
SDS Foil no 1 V&V&S Verification, Validation and Synthesis: doing away with defects Verification, Validation and Synthesis: doing away with defects.
Requirements Engineering-Based Conceptual Modelling From: Requirements Engineering E. Insfran, O. Pastor and R. Wieringa Presented by Chin-Yi Tsai.
Collaboration Entities on Deterministic Finite Automata Minjun Wang Department of Electrical Engineering and Computer Science Syracuse University, U.S.A.
Understanding the Behavior of Java Programs Tarja Systa Software Systems Lab. Tampere Univ. Sookmyung Women’s Univ. PSLAB Choi, yoon jeong.
Compiler Introduction 1 Kavita Patel. Outlines 2  1.1 What Do Compilers Do?  1.2 The Structure of a Compiler  1.3 Compilation Process  1.4 Phases.
Chapter 1: Fundamental of Testing Systems Testing & Evaluation (MNN1063)
Software Engineering Requirements + Specifications.
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
RE-ENGINEERING AND DOMAIN ANALYSIS BY- NISHANTH TIRUVAIPATI.
1 The Software Development Process ► Systems analysis ► Systems design ► Implementation ► Testing ► Documentation ► Evaluation ► Maintenance.
Winter 2007SEG2101 Chapter 121 Chapter 12 Verification and Validation.
Overview of Previous Lesson(s) Over View  A token is a pair consisting of a token name and an optional attribute value.  A pattern is a description.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
OBJECT-ORIENTED TESTING. TESTING OOA AND OOD MODELS Analysis and design models cannot be tested in the conventional sense. However, formal technical reviews.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
CS5270 Lecture 41 Timed Automata I CS 5270 Lecture 4.
Verification of Data-Dependent Properties of MPI-Based Parallel Scientific Software Anastasia Mironova.
Formal Specification.
Software Engineering (CSI 321)
4b Lexical analysis Finite Automata
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
4b Lexical analysis Finite Automata
Presentation transcript:

Friday, April 17, 2015 Requirements Specifications Interaction Analysis Bill Mitchell Software and Systems Research Labs Motorola UK Research Labs Bill Mitchell Department of Computing University of Surrey

Motorola Labs 2 Reality of Engineering Requirements Specifications Rapid development of lightweight specifications Specification by example scenarios Poor coverage of scenarios Disjoint engineering groups with little communication Extreme pressure to ship on time Hence large number of defects only found in field testing

Motorola Labs 3 Research Project Pilot Current Pilot coordinated by Motorola UK Research lab with: UI Design Group UI Software Tool Development Labs System Architecture Group Testing Group Testing Tools Software Management Group Requirements Specification Managers FATCAT an internal tool, takes sets of scenarios (in e.g MSC notation): analyse scenarios coverage find conflicts construct interesting FI tests EU 6th Framework STReP, Forming a consortium:

Motorola Labs 4 Standard Techniques Internal study of 200 TETRA MSC scenarios with Spin and standard MSC automata synthesis algorithms (Alur, Leue etc). Result: state explosion generated many “bogus” errors Two other Motorola Research Labs built POTS system with Switch in SDL for model checking with FDR. Result: state explosion problems only found conflicts when the algorithm directed towards error states For wireless telecomms specifications, standard model checking not always the right approach

Motorola Labs 5 Purpose of MSC Specifications Specs define Phase Transitions Each phase describes a meaningful part of the overall operation of the system. Each phase involves its own mini-protocol. Each MSC shows how to move from one phase to another, via intermediate phases. Activate Handset Idle Call Set-up Call Queued Allocate Resource Call Progressing

Motorola Labs 6 Example, Call Waiting from paper in FIW 2000 SysBCD call_setup[B] call(B) accept(D) hang_up_on(C) ack_accept(D) disconnect(B) call_active(B) call_active[B,D] idle call_active[B,C]

Motorola Labs 7 Example, Ring Back When Free, from paper in FIW 2000 ASysB call_setup[B] call(B) rbwf(B) call_active[B,C] hang_up_on(C) idle ring(A,B) rbwf_call_progressing[A,B]

Motorola Labs 8 Example, FI from paper in FIW 2000 ASysBC call_setup[B] call(B) rbwf(B) D call_setup[B] idle call(B) accept(D) hang_up_on(C) ack_accept(D) disconnect(B) call_active(B) call_active[B,D] idle call_active[B,C]

Motorola Labs 9 Naive Deterministic FSA implementation Each instance to be implemented as a FSA Next state after each event is unique except where this causes nondeterminism FSA must be deterministic Phases define unique states in implementation

Motorola Labs 10 Deadlock Example AB S0 S2 a c S0 S1 S3S2 !a FSA for A S1 AB S0 S3 b d S1 !b !c?d S0 S1 S3S2 ?a FSA for B ?b ?c!d

Motorola Labs 11 Deterministic FSA implementation with Phases Better Semantics? Each instance to be implemented as a DFSA Phases correspond to set of states in DFSA (composite state) Restrict construction of DFSA from MSC via additional semantics of phases.

Motorola Labs 12 Phase Traces, Phase Automaton AB S0 S2 a c S1 b d Phase trace for A: S0, !a, S0, ?b, S0, !c, S1, ?d, S2 !a ?b !c ?d S0 S1S2 DFSA for A

Motorola Labs 13 Additional Phase Semantics, First Attempt Booby Trapped Semantics If a DFSA path has an execution trace which matches the initial section of an MSC phase trace then the implementation can always generate the rest of the phase trace from that point.

Motorola Labs 14 Consequences of Bad Semantics AB S0 a a S1 b b x !a ?b S0 S1 DFSA for A y !a ?b !a

Motorola Labs 15 Corrected Additional Phase Semantics If a DFSA path has an execution trace that matches a trace precursor and it has reached a point where a phase transition is possible then the implementation can always generate the rest of the phase trace from that point. S0, !a, S0, ?b, S0, !c, S1, ?d, S2 Trace Precursor Phase Change

Motorola Labs 16 Overlapping Threads S0 S1S2 ?a !b ?c !d uv DFSA for B AB S0 S2 a c S1 b d w x y

Motorola Labs 17 Overlapping Threads S0 S1S2 ?a !b ?c !d uv Extended DFSA for B AB S0 S3 c S1 e S3 z !e Additional MSC Scenario w x y

Motorola Labs 18 Missing Scenarios for Browser Suspend MRS Scenario 1: browser active downloading file, incoming EMS Scenario 2: browser suspended, voice call active, incoming EMS Missing Scenarios Could generate 14 missing use cases. FATCAT only outputs 2. These are the significant ones. Missing scenarios could be used purely for test purposes, or could be used for additional requirements specifications. EMS Phone Crashes download screen saver Actual Escaped Defect in the T720 (only found during field testing)

Motorola Labs 19 Process Algebra for overlapping recursive processes

Motorola Labs 20 Questions

Motorola Labs 21 Missing Scenarios generic composite state generic event Wild card state, matches any composite state that interfaces with Air_Interface process. Since ‘browser_active’ has use case where it accepts ‘?incoming_call’ from Air_Interface, wild card can be identified with ‘browser_active’. If a trace in the phase automaton can reach here need to check whether this represents a true missing scenario. This will be true exactly where there is not other transition triggered by generic event. Automatically generate generic abstract use case from UI guide

Motorola Labs 22 Phase Automaton for Browser MSC-s Because ‘Any_Active_Phase’ can match against ‘incall_view’ the phase semantics then force state 5 to transition to ‘MISSING_SCENARIO’ via the ‘?incoming_EMS’ event. Checking against known use cases shows there is no requirement specification to determine what the correct transition for 5 should be at this point, so this transition does define a missing scenario.

Motorola Labs 23 Questions?

Motorola Labs 24 MSC Representation of UI Use Cases for WAP Browser MSC-s based on translation of UI semantics into abstract representation

Motorola Labs 25 Phase Automaton with Conflict The phase semantics force the use cases to be combined as shown. This trivial example does not require the subtlety of the phase semantics, but it clearly illustrates how use cases are combined within a single process representation. Error since END causes nondeterministic transition

Motorola Labs 26 Overlapping MSC AB S0 S2 a c S1 b d S3 e ALT These overlapping MSC can be generated directly from the original MSC-s.

Motorola Labs 27 Leads to false Deadlock AB S0 a c S1 d Deadlock

Motorola Labs 28 Example Deadlock Avoided AB S0 S2 a c S1 AB S0 S3 b d S1 S0 S1S2 !a !b !c Extended DFSA for B S3 ?d

Motorola Labs 29 Initial Phase Trace Precursor S0S1S2 uvwxy ab c d S0, a, S0, b, S1, c, S1, e, S3

Motorola Labs 30 Initial Phase Trace Precursor 2 S0S1S2 uvwxy ab c d S3 z w’x’ c b e

Motorola Labs 31 Initial Phase Trace Precursor 3 S0S1S2 uvwxy ab c d S3 z e