MICON 2000 F ormal methods for design methodology by Luigi Logrippo with D. Amyot, R. Chan, L. Charfi, N. Gorse, J.Sincennes, R. Plesa,... S CHOOL OF I.

Slides:



Advertisements
Similar presentations
UCM Path Traversal Daniel Amyot SG17, Geneva, March 5 th, 2002 UCM Scenarios and Path Traversal.
Advertisements

Restricted © Siemens AG All rights reserved Siemens Corporate Technology | Month 20XX Proposed topics for TDL phase 3.
Friday, April 17, 2015 Requirements Specifications Interaction Analysis Bill Mitchell Software and Systems Research Labs Motorola UK Research Labs Bill.
SWEN 5130 Requirements EngineeringSlide 1 Software Prototyping u Animating and demonstrating system requirements.
Daniel Amyot, PhD student, University of Ottawa Scenarios As First-Class Entities Functional Entities Mapping Scenarios on Functional Entities Network.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
7M701 1 Software Prototyping Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 8
August Moscow meeting1August Moscow meeting1August Moscow meeting11 Deductive tools in insertion modeling verification A.Letichevsky.
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
1 Luigi Logrippo SITE Feature Interactions as Inconsistencies
ISBN Chapter 3 Describing Syntax and Semantics.
1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture 05.
Automated creation of verification models for C-programs Yury Yusupov Saint-Petersburg State Polytechnic University The Second Spring Young Researchers.
© Betty HC Cheng. This presentation is available free for non-commercial use with attribution under a creative commons license. Acknowledge: S.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
Chapter 1 Software Engineering. Homework ► Read Section 2.2 (pages 79-98) ► Answer questions: ► 7, 8, 11, 12, & 13 on page 134. ► Answer on paper, hand.
Describing Syntax and Semantics
IS550: Software requirements engineering Dr. Azeddine Chikh 4. Validation and management.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Software Testing and QA Theory and Practice (Chapter 10: Test Generation from FSM Models) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory.
Verification and Validation
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Formal Techniques for Verification Using SystemC By Nasir Mahmood.
System Design Chapter 8. Objectives  Understand the verification and validation of the analysis models.  Understand the transition from analysis to.
A Visual Interactive Tool For the Course “Automata and Formal Languages” Holon Institute of Technology Mark Trakhtenbrot, Vladimir Nodelman, Avi Lamai.
Verification and Validation Yonsei University 2 nd Semester, 2014 Sanghyun Park.
UCM-Based Generation of Test Goals Daniel Amyot, University of Ottawa (with Michael Weiss and Luigi Logrippo) RDA Project (funded.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Verification and Validation.
Ontology Development Kenneth Baclawski Northeastern University Harvard Medical School.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
CS 360 Lecture 6.  A model is a simplification of reality  We build models to better understand the system being developed.  We build models of complex.
Chapter 11: Software Prototyping Omar Meqdadi SE 273 Lecture 11 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA, C ANADA Daniel Amyot Q18/17 (URN) Rapporteur User Requirements.
Software Engineering Research paper presentation Ali Ahmad Formal Approaches to Software Testing Hierarchal GUI Test Case Generation Using Automated Planning.
1 Presentation and tool by Jason Kealey University of Ottawa CSI5180 Automatic conversion of Use Cases to Use Case Maps.
GENERATION OF PROTOCOLS FOR TELEPHONY FEATURES FROM SCENARIO REQUIREMENTS By Luigi Logrippo University of Ottawa School of Information Technology and.
Automatic Test Generation from here until the end (of my Phd.) University of Geneva Levi Lúcio SMV & Les Diablerets.
Verification and Validation in the Context of Domain-Specific Modelling Janne Merilinna.
소프트웨어공학 강좌 1 Chap 7. Software Prototyping - Rapid software development to validate requirements -
1 Recent work in the area: Requirement-Driven Development of Distributed Applications Gregor v. Bochmann School of Information Technology and Engineering.
S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA Feature Description and Feature Interaction Analysis with Use Case Maps and.
Formal Verification Lecture 9. Formal Verification Formal verification relies on Descriptions of the properties or requirements Descriptions of systems.
1 Representing New Voice Services and Their Features Ken Turner University of Stirling 11th June 2003.
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.
1 Overview of the project: Requirement-Driven Development of Distributed Applications School of Information Technology and Engineering (SITE) University.
1 Features as Constraints Rafael AccorsiUniv. Freiburg Carlos ArecesUniv. Amsterdam Wiet BoumaKPN Research Maarten de RijkeUniv. Amsterdam.
Software Prototyping Rapid software development to validate requirements.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Generating Software Documentation in Use Case Maps from Filtered Execution Traces Edna Braun, Daniel Amyot, Timothy Lethbridge University of Ottawa, Canada.
Chapter 2 – Software Processes Lecture 1 1Chapter 2 Software Processes.
Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003.
Facilitating testing and monitoring of number entry systems in medical devices Abigail Cauchi, Christian Colombo, Mark Micallef & Gordon Pace.
S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA, C ANADA Daniel Amyot Q18/17 (URN) Rapporteur User Requirements.
International Telecommunication Union © ITU-T Study Group 17 Integrated Application of SDL Amardeo Sarma NEC Europe Ltd.
1 Luigi Logrippo SITE Feature Interactions as Inconsistencies
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Software Engineering, 8th edition. Chapter 4 1 Courtesy: ©Ian Sommerville 2006 FEB 13 th, 2009 Lecture # 5 Software Processes.
© 2000 D EMO D AY 2000 Page 1 Automatic Generation of Conformance Test Cases from Use Case Maps Strategic Technology Leïla Charfi, Luigi Logrippo & group.
Verification vs. Validation Verification: "Are we building the product right?" The software should conform to its specification.The software should conform.
Topics  Direct Predicate Characterization as an evaluation method.  Implementation and Testing of the Approach.  Conclusions and Future Work.
Model Checking Early Requirements Specifications in Tropos Presented by Chin-Yi Tsai.
Description of WIN Incoming Call Screening Service using Use Case Maps
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Participants and Collaborators
Verification and Validation Unit Testing
IS 2935: Developing Secure Systems
Model Based Testing Venkata Ramana Bandari, Expert Software Engineer
Presentation transcript:

MICON 2000 F ormal methods for design methodology by Luigi Logrippo with D. Amyot, R. Chan, L. Charfi, N. Gorse, J.Sincennes, R. Plesa,... S CHOOL OF I NFORMATION T ECHNOLOGY AND E NGINEERING U NIVERSITY OF O TTAWA

Basic Idea n Use Case Maps provide a good basis for high-level description and design of many aspects of telecom systems n LOTOS is a formal language that matches UCMs in level of abstraction n Translate UCMs into LOTOS and then use LOTOS formal methodology n The LOTOS spec is a ‘formal prototype’ for the UCM requirements

What does this buy us n Validation and Verification Feature Interaction Detection n Semi-automatic derivation of functional test cases n Semi-automatic derivation of implementations n The design process extends itself into implementation and testing

From UCMs to L OTOS Start/end points Responsibilities Agents/components Stubs Plug-ins Inter-path causality Databases, conditions Visible gates Hidden gates Processes Processes (implement selection policies) Processes Hidden inter-process synchronization (msg) Abstract Data Types

Interprocess Communication n LOTOS process synchronization concept can be implemented as a blackboard system n Establishing a relation with a methodology already in place at Mitel

UCM to LOTOS example Process Agent[A_U, U_A, A_A, req]: (a:Agent, u:User):= U_A !u !a !conReq ?dU:User; req !dU ?dA; A_A !a !dA !conReq !dU; ( A_A !dA !a !conConf !ring; A_U !a !u !conConf !ring; exit [] (* - OR - *) A_A !dA !a !conConf !busy; A_U !a !u !conConf !busy; exit ) endproc Process User[ dial, U_A, A_U, ringBack, busyTone ]:(a:Agent, u:User):= dial !u ?dU:User; U_A !u !a !conReq !dU; ( A_U !a !u !conConf !ring; ringBack; exit [] (* - OR - *) A_U !a !u !conConf !busy; busyTone; exit ) endproc

How to use LOTOS methodology n LOTOS can be used to ‘execute’ UCMs  Scenarios for the UCMs can be obtained Validation tools can be applied to detect errors Functional test cases can be obtained

Detection of feature interactions n New, more efficient methods developed n Have both static and dynamic feature interaction detection n Proven performance: second place (very near to 1st) in 2000 Feature Interaction contest (Glasgow, Scotland)

Feature Interaction Detection Using Predicate Logic, UCM and LOTOS n Feature Interaction Filtering at requirement stage using Prolog Identification of possible interactions Based on requirements n Based on the UCM model Validation of the global model n Rapid method Nicolas Gorse Master Thesis

Feature Interaction Detection Using Predicate Logic, UCM and LOTOS (cont’d) n Derivation of a LOTOS specification Provides an executable model Provides information for scenario generation n Scenario Generation for possible Interactions identified Using information on the structure of the feature Based on possible interactions identified

Feature Interaction Detection Using Predicate Logic, UCM and LOTOS (cont’d) n Feature Interaction scenario-based validation of the LOTOS specification Allows to verify whether the possible interactions identified are present in the LOTOS spec Method only identifies possible interactions, however experimental study showed very high hit rate Scenarios derived can be reused at final system testing stage

n Representation of features Pre-conditions CFA: {subs(B, cfa), concerns(B, cfb), cfa(C)} CFB: {subs(B, cfb), concerns(B, cfb), busy(A), cfb(D) Triggering Events CFA: {call(A, B)} Same triggering events CFB: {call(A, B)} for both features Results CFA: {call(A, C)} Different results, CFB: {call(A, D)} non determinism Feature Interaction Filtering Using Predicate Logic

Feature Interaction Filtering Using Predicate Logic (cont’d) n Mitel Project 22 feature descriptions (484 pairs), 4 users 43 possible interactions found in secs n Feature Interaction Contest 97 feature descriptions (9409 pairs), 4 users 149 possible interactions found in secs n The representation of features is fairly quick to obtain

Another application: Derivation of Test Cases

The Big Picture UCMS LOTOS specification test purposes mapping M mapping M LOTOS scenarios Validation with LOLA TGV TTCN test suites MSC generation LOTOS scenarios used for : (1) the spec validation (2) the TTCN test suite generation (1) (2) Leila Charfi’s Master thesis Several Tools used: LOLA CAESAR TGV (in CAESAR ) lot2msc...

busy idle incomingCall initiateCall onHook disconnection Phone 1 Switch Phone 2 offHook ringStub CallerdisconnectionCalleedisconnection onHook disconn busy offHook talk ring ringBack

A coverage algorithm uses the internal representation of the UCM to cover all possible paths at least once

phone1: startpoint ‘offHook’ ; phone1: resp ‘initiateCall’; phone2: resp ‘incomingCall’; phone2: point ‘busy’; phone1: point ‘busy’; phone1: endpoint ‘onHook’; phone1: startpoint ‘offHook’ ; phone1: resp ‘initiateCall’; phone2: resp ‘incomingCall’; phone2: point ‘idle’; ( phone2: resp ‘ring’; exit ||| phone1: resp ‘ringBack’; exit ) >> phone2: resp ‘offHook’; switch: point ‘talk’; phone2: startpoint ‘onHook’; switch: resp ‘disconn’; phone1: startpoint ‘offHook’ ; phone1: resp ‘initiateCall’; phone2: resp ‘incomingCall’; phone2: point ‘idle’; ( phone2: resp ‘ring’; exit ||| phone1: resp ‘ringBack’; exit ) >> phone2: resp ‘offHook’; switch: point ‘talk’; phone1: startpoint ‘onHook’; switch: resp ‘disconn’; user_to_phone !A !offHook; phone_to_user !A !dialTone; user_to_phone !A !dial !B; ( phone_to_user !B !ringingOn; exit ||| phone_to_user !A !ringBackTone; exit ) user_to_phone !B !offHook; phone_to_user !A !ringBackToneOff; user_to_phone !B !onHook; phone_to_user !A !disconnectTone; user_to_phone !A !onHook; lotos scenario scenarioBusyCalleescenarioForwardTakeDownscenarioBackwardTakeDown des (0, 14, 14) (0, "USER_TO_PHONE !A !OFFHOOK", 1) (1, "PHONE_TO_USER !A !DIALTONE", 2) (2, "USER_TO_PHONE !A !DIAL !B", 3) (3, "PHONE_TO_USER !B !RINGINGON", 4) (3, "PHONE_TO_USER !A !RINGBACKTONE", 5) (4, "PHONE_TO_USER !A !RINGBACKTONE", 6) (5, "PHONE_TO_USER !B !RINGINGON", 6) (6, i, 7) (7, "USER_TO_PHONE !B !OFFHOOK", 8) (8, "PHONE_TO_USER !A !RINGBACKTONEOFF", 9) (9, "USER_TO_PHONE !B !ONHOOK", 10) (10, "PHONE_TO_USER !A !DISCONNECTTONE", 11) (11, "USER_TO_PHONE !A !ONHOOK", 12) (12, ACCEPT, 12) scenario Aldebaran format

ADT lotos spec scenarios from UCMUCM TGV test suite lotos scenario bcg_min scenario CAESAR ENVIRONMENT Choose scenarios to cover all UCM

scenarioForwardTakeDown Test suite generated with TGV

New Topics: CPL and SIP n CPL, the SIP Call Processing Language CPL has a logic somewhat similar to the one of LOTOS: communicating processes, with no explicit notion of state Develop formal semantics for CPL based on LOTOS Develop FI detection methods for CPL based on LOTOS

New Topics: The whole method n Exploring the relation between interaction resolution methods (e.g. OPI) UCMs, LOTOS-based methods n Three methodologies that must work together but are not (yet) clearly coordinated where do we start, how to use them together

Proof of concept has been provided, but many challenges are ahead...