IST-2001 - Project 33522 IST-2001-33522 Animation and formal - - PowerPoint PPT Presentation

▶
ist 2001 project 33522
SMART_READER_LITE
LIVE PREVIEW

IST-2001 - Project 33522 IST-2001-33522 Animation and formal - - PowerPoint PPT Presentation

Sep 19, 2023 213 likes •488 views

OMEGA OMEGA IST-2001 - Project 33522 IST-2001-33522 Animation and formal verification of a component-based application using live sequence charts (LSCs) and the Play-Engine Omega workshop Grenoble February 17, 2005 Pierre Combes

slide-1
SLIDE 1

OMEGA Workshop - Grenoble, February 17, 2005 1

OMEGA OMEGA

IST-2001-33522

IST-2001 - Project 33522 Animation and formal verification

  • f a component-based application

using live sequence charts (LSCs) and the Play-Engine

Omega workshop Grenoble – February 17, 2005 Pierre Combes (FTR&D), Hillel Kugler(Weizmann Institute)

slide-2
SLIDE 2

OMEGA Workshop - Grenoble, February 17, 2005 2

OMEGA OMEGA

IST-2001-33522

Using the Play-Engine and LSCs for studying a Telecom application (Depannage by FTRD)

Play-Engine Tool Language : Live Sequence Charts (LSCs) Specification of Requirements – Play-In Execution of Requirements – Play-Out Smart Execution and Verification – Smart Play-Out

Motivation for work

Modeling in LSCs is a new approach Evaluation by Industrial user and not the tool developer Case Study Represents broader class of applications

slide-3
SLIDE 3

OMEGA Workshop - Grenoble, February 17, 2005 3

OMEGA OMEGA

IST-2001-33522 Extend visual formalism used for requirements:

message sequence charts (MSCs)

slide-4
SLIDE 4

OMEGA Workshop - Grenoble, February 17, 2005 4

OMEGA OMEGA

IST-2001-33522

Live sequence charts (LSC’s)

“LSC’s: Breathing Life into Message Sequence Charts”

(Damm & Harel, ‘98 )

A natural extension of classical MSCs, with modalities (universal/existential, hot/cold, etc.) and structure (subcharts, conditionals, loops, etc.)

slide-5
SLIDE 5

OMEGA Workshop - Grenoble, February 17, 2005 5

OMEGA OMEGA

IST-2001-33522

Basic form of a universal LSC

prechart (if) main chart (then)

slide-6
SLIDE 6

OMEGA Workshop - Grenoble, February 17, 2005 6

OMEGA OMEGA

IST-2001-33522

Existential LSC

slide-7
SLIDE 7

OMEGA Workshop - Grenoble, February 17, 2005 7

OMEGA OMEGA

IST-2001-33522

System (composite) and Components

A component-based approach A system (composite) is built from a set of embedded

components

The system (composite) is specified by a set of requirements The architecture of the system is built from components and connectors: an architectural model Assumptions could be associated to connectors

  • Introduction of delays, time constraints, loss message rates

Components are described by

A set of interfaces (required and provided) Assumptions (abstract behaviors) on their interfaces

  • Components should be reusable
slide-8
SLIDE 8

OMEGA Workshop - Grenoble, February 17, 2005 8

OMEGA OMEGA

IST-2001-33522

The Service: Depannage (Emergency)

A telecommunication service A User (fixed phone but mainly for mobile phone) calls a

specific number in order to find assistance service (depannage but also urgency: police, fire brigade, doctor)

The objective is to connect the user, as quickly as possible, to

a member of the depannage society

  • Which is at a location nearby the user location
  • Call attempts are done for different potential called numbers (in

sequential or in parallel)

  • In any case, the caller should be connected to a vocal box or a

secretariat

The depannage society has several employees

  • Moving and which could be busy (by another client, or by another
  • ccupation) or not accessible (in a concert hall!)
slide-9
SLIDE 9

OMEGA Workshop - Grenoble, February 17, 2005 9

OMEGA OMEGA

IST-2001-33522

The Service: Depannage (Emergency)

Based on a set of service and platform components (embedded

in mobile terminals or core network)

Service Features: authentication, location, search (in sequential, in

parallel), etc

Interface Features (for session control, user interface, location, discovery) Platform Components (communication between platform(s) and network)

The environment model includes the users, the network and the

location architecture

Timed and Un-timed Requirements at the system level Many Time constraints in service components, component

interactions and environment

Time constraints that could lead to unexpected behaviours

slide-10
SLIDE 10

OMEGA Workshop - Grenoble, February 17, 2005 10

OMEGA OMEGA

IST-2001-33522

Component modeling with LSC

Components:

Described independently of any embedding system Described as a black box

Interfaces (signatures) and Ports

Described as a grey box

The abstract view (assumptions) of the behaviour of each

component on its interfaces

Time constraints and Delays due to the specific platform (on task

execution), periodic requests, etc

With help of Universal LSC

slide-11
SLIDE 11

OMEGA Workshop - Grenoble, February 17, 2005 11

OMEGA OMEGA

IST-2001-33522

Component

SearchOnList

Data Data Search_Data_Base Search_Data_Base SearchApi CallControl_Service CallControl_Service SearchService SearchOnList_Service SearchOnList_Service

Abstraction

Described by a set of LSCs Independently of any embedded system

<<interf ace>>

SearchOnList_Service

+EstablishSearch():Boolean +EstablishTimedSearch():Boolean +SearchSecre():Boolean + EstablishDuo():Boolean

<<interf ace>>

SearchOnList_Service

+EstablishSearch():Boolean +EstablishTimedSearch():Boolean +SearchSecre():Boolean + EstablishDuo():Boolean

<<interf ace>>

CallControl_Service

+ LegDest():Boolean + Creer2Leg ():Boolean + ConnectedLeg(Integer, inout EventGroup):Boolean + ReleaseLeg(Integer):Boolean + ReleaseCall (): Boolean

<<interf ace>>

CallControl_Service

+ LegDest():Boolean + Creer2Leg ():Boolean + ConnectedLeg(Integer, inout EventGroup):Boolean + ReleaseLeg(Integer):Boolean + ReleaseCall (): Boolean

slide-12
SLIDE 12

OMEGA Workshop - Grenoble, February 17, 2005 12

OMEGA OMEGA

IST-2001-33522

Search On List

Ports Core of the component

slide-13
SLIDE 13

OMEGA Workshop - Grenoble, February 17, 2005 13

OMEGA OMEGA

IST-2001-33522

Search On List

T is recorded, just after the sending of LegDest If time evolution is Under 1, then try another Destination party The main chart is executed On reception of LegCallReturn ports

slide-14
SLIDE 14

OMEGA Workshop - Grenoble, February 17, 2005 14

OMEGA OMEGA

IST-2001-33522

Composite Modeling with LSC

Based on UML2 architectural diagram

Express Requirement (Existential LSC) from the system

(composite) point of view

Static description of embedded components and connectors Express the dynamic behaviour (assumptions) on connectors

(Universal LSCs),

Time constraints, Delays , Message losses on protocols and

communications (with probabilities)

Express the environment potential behaviours (Universal LSCs)

Great use of symbolic instances

Remark: we did not develop graphical user interface

slide-15
SLIDE 15

OMEGA Workshop - Grenoble, February 17, 2005 15

OMEGA OMEGA

IST-2001-33522

The Composite: an architectural view

active public class Service_And_Features Architecture Diagram {3/6} active public class Service_And_Features Architecture Diagram {3/6}

API API API Data Data

+InstLocation : Location[0..20]/0 +InstLocation : Location[0..20]/0

Dser Dser Location Location Data Data ServiceToLocation Location_Service ServiceToLocation Location_Service

+InstCallControl:CallControl[0..20]/0 +InstCallControl:CallControl[0..20]/0

SF SF API API SF SF LocationToAPI ServiceFeaturesToLocationAPI ServiceFeaturesToLocationAPI APIToCC ServiceFeaturesToAPI APIToServiceFeatures APIToCC ServiceFeaturesToAPI APIToServiceFeatures LocationToData Location_Data_Base LocationToData Location_Data_Base ServiceTocc CallControl_Service ServiceTocc CallControl_Service

+ InstSearch:SearchOnList[0..20]/0 + InstSearch:SearchOnList[0..20]/0

Data Data CallControl CallControl SFServices SFServices SearchToData Search_Data_Base SearchToData Search_Data_Base SearchToCC CallControl_Service SearchToCC CallControl_Service ServiceToSearch SearchOnList_Service ServiceToSearch SearchOnList_Service

+InstDepannage:serviceDepannage[0..20]/0 +InstDepannage:serviceDepannage[0..20]/0

S1API S1API CControl CControl Search Search Acces Acces Location Location APIToService NotifyApplication APIToService NotifyApplication

slide-16
SLIDE 16

OMEGA Workshop - Grenoble, February 17, 2005 16

OMEGA OMEGA

IST-2001-33522

Simple Connections

slide-17
SLIDE 17

OMEGA Workshop - Grenoble, February 17, 2005 17

OMEGA OMEGA

IST-2001-33522

Connections with Delay

On the connector (by signal) On a port/interface

The delays could depend on the signal, the parameters, the history, etc We may introduce signal loss and loss rates

slide-18
SLIDE 18

OMEGA Workshop - Grenoble, February 17, 2005 18

OMEGA OMEGA

IST-2001-33522

The Environment: GSM user

Answer before T + 1 Answer after T + 2 Busy after T + 1

slide-19
SLIDE 19

OMEGA Workshop - Grenoble, February 17, 2005 19

OMEGA OMEGA

IST-2001-33522

Animation of LSC Model

Animation for a better understanding of the model

execution

Executing different scenarios/configurations Recording the traces Observing the existential LSCs

On the use of LSCs and the Play-In tool

  • LSC is well-suited for the expression of requirements and

dynamic assumptions on different parts of the model (components, connectors, system)

A graphical language accessible to non-specialist in formal theory Great expressivity Great flexibility

slide-20
SLIDE 20

OMEGA Workshop - Grenoble, February 17, 2005 20

OMEGA OMEGA

IST-2001-33522

Play-Out scenario

slide-21
SLIDE 21

OMEGA Workshop - Grenoble, February 17, 2005 21

OMEGA OMEGA

IST-2001-33522

Formal Verification with smart Play-Out

Principe of the Play-Out Engine

To find one execution that satisfies a existential LSC (the

property)

Principe of formal verification

Check that, for all executions, a requirement is respected (not

violated)

Principe of the verification method

Express the requirement by a property (an existential LSC) that

violates it

Run the Play-Out engine If the property is satisfied, then the requirement is violated (for

at least one execution path)

If the property is not satisfied, the requirement is verified for all

execution paths

slide-22
SLIDE 22

OMEGA Workshop - Grenoble, February 17, 2005 22

OMEGA OMEGA

IST-2001-33522

Formal Verification with smart Play-Out

Time requirements

We mainly want to verify requirements such as:

D1 <Time_Duration < D2 Time_Duration is the end-to-end execution delay

Example: Time_Duration < D2

We express the property by a existential LSC with a condition

  • Time_Duration ≥ D2

Running the Play-Out Engine, the property is not satisfied

slide-23
SLIDE 23

OMEGA Workshop - Grenoble, February 17, 2005 23

OMEGA OMEGA

IST-2001-33522

Formal Verification with smart Play-Out

Restrictions on the smart Play-Out

No symbolic instances Multiple parameters in signal

State-explosion problem Needs to make several models

Focusing on specific parts of the model (more complex/critical) Reducing non determinism

Use of configuration

Feedback on the complete model

Very good compromise between formal techniques

and readability

Three examples

slide-24
SLIDE 24

OMEGA Workshop - Grenoble, February 17, 2005 24

OMEGA OMEGA

IST-2001-33522

1 Existential LSC

Not satisfied Satisfied

For all execution Time_Duration will be more (or equal) than 1

slide-25
SLIDE 25

OMEGA Workshop - Grenoble, February 17, 2005 25

OMEGA OMEGA

IST-2001-33522

2 Another Time Requirements

Not satisfied

Always, the end-to-end delay will be Less than 4

slide-26
SLIDE 26

OMEGA Workshop - Grenoble, February 17, 2005 26

OMEGA OMEGA

IST-2001-33522

3 Search Component

slide-27
SLIDE 27

OMEGA Workshop - Grenoble, February 17, 2005 27

OMEGA OMEGA

IST-2001-33522

3 Search Property

Satisfied with the second configuration: Adding a new feature (Forward) No satisfied with first configuration If user3 makes quickanswer, The return should not be answer