11.08 EuRailCheck 1 The Methodology Angelo Susi Software Engineering Unit - FBK-Irst [email protected]

11.08 EuRailCheck 1

The Methodology

Angelo Susi

Software Engineering Unit - FBK-Irst

[email protected]

11.08 EuRailCheck 2

Organization of the course• Requirements informal representation and analysis phase• Requirements formalization phase• Requirements validation phase

How we would like to proceed• Theoretical vision of the

– methodology

– concepts

• The support of the tool to the methodology• Examples on the tool• Hands-on to complete the examples

We will use a set of requirements as example

11.08 EuRailCheck 3

ETCS: notes on the project

11.08 EuRailCheck 4

Focus: requirements, not model

• In traditional formal verification– the design is under analysis– the requirements are taken as "golden"– verification means checking compliance

• Here the goal is to– enhance quality of requirements

• A much harder task!

11.08 EuRailCheck 5

Why is it so hard?• Requirements analysis is a pervasive problem in nowadays industry

– In hardware design, standards for languages to represent properties and design intent are emerging (e.g. PLS, SVA)

• Problem 1: Natural language– ambiguous– hard to process automatically with NLP– requires background information

• Problem 2: when are my requirements good?– are they too strict? Are some required behaviours being (wrongly)

disallowed?– are they too weak? Are some undesirable behaviours being (wrongly)

allowed?

• The source of the matter is that what is being modeled is informal– the design intent that must be captured by the specification is in the

head of the specifier

11.08 EuRailCheck 6

Issues of interest in this project

• Issue1: Bridging the gap between natural language and formal analysis

• issue2: providing methods for pinpointing flaws in requirements

• And also (as usual) …– Integration within requirements engineering flow– Usability

• Avoid intricate formalisms• Hide formal methods with semiformal representations

– Automation of the verification process• Model checking

11.08 EuRailCheck 7

From Informal to FormalNATURAL LANGUAGE

SEMIFORMALLANGUAGE

FORMAL LANGUAGE

11.08 EuRailCheck 8

Steps of the methodologyM1 Informal analysis phase:

– categorization and structuring of the informal requirements fragments described in the requirements document to produce categorized requirement fragments

M2 Formalization phase:– categorized requirement fragments are described trough the set of

concepts and diagrams in UML – constraints in Controlled Natural Language (CNL) are added to produce

formalized requirement fragments

M3 Formal validation phase: – identification of a subset of the formalized requirement fragments– definition of the validation problems – automatic validation analysis

11.08 EuRailCheck

M1 (Requirement categorization andStructuring)viaRequisite Pro

M2 (Requirements Formalization)viaRational Software Architect

M3 (Problem Definition) viaRSA plug-in

Interpretation ofMC Results

M3 (Model Checking)viaNuSMV

11.08 EuRailCheck 10

• Categories of requirement fragments– definitions– properties – behavior– …

• discrepancies in requirements according to "traditional" RE principles– checklist inspection wrt guidelines– finding dependencies and obvious conflicts

• Annotate requirement fragments according to categories

Management of natural language specifications


M1: Informal Analysis PhaseM1.1

isolation of the fragments that identify basic units of the domain requirements document

M1.2

categorization of the informal requirement fragments

M1.3

creation of the dependencies among the informal requirement fragments

M1.4

analysis of the informal requirement fragments based on standard inspection-based software engineering

=> Using Rational Software Architect with RequisitePro plug-in functionalities


Categories of requirement fragments (M1.1-M1.2)

Category Acronym Description

Glossary GLS The requirement defines a particular concept in ETCS domain

Architecture ARC The requirement introduces some system's modules and de scribes how they interact

Functionality/behavioural BEH The requirement describes the steps a p articular module perform or the states where the module can be

Communication COM The requirement describes the messages some modules exchange

Environmental ENV The requirement describes some constraints on the model

Scenario SCE The requirement describes a possible scenario of the ETCS

Property PRP The requirement describes an expe cted property of the ETCS

Annotation NTE Notes in the specifications

The categories are also used to guide the formalization in M2 by suggesting to use a particular language construct (UML element/CNL constraint)


Checklist


Example from the Movement Authority section of the Specifications

3.8.3.2 For each section composing the Movement Authority thefollowing information shall be given;a) Length of the sectionb) Optionally, Section time-out value and distance from beginning of section to Section Time-

out stop location

3.8.3.3 In addition, the End section of the Movement Authority may include;a) End Section Time-out value and distance from the End Section Time-out start location to

the end of the last sectionb) Danger point information (distance from end of section to danger point, release speed

related to danger point)c) Overlap information (distance from end of section to end of overlap, time-out, distance

from overlap time-out start location to end of section, release speed related to overlap)

An example of requirement




out stop location





Fragments of these requirements can be classified as “glossary”

An example of requirement isolation and categorization




out stop location





Fragments of these requirements can be classified as “glossary”

An example of requirement isolation and categorization

11.08 EuRailCheck

Eclipse Platform

Requisite Pro RSA

Models

Rational Software Architect

Eclipse Plugins API

EMF

MS Word

NuSMV

UML2

RSA View

ETCS Plugins MCFrontend

Tool SW Architecture

RSA

11.08 EuRailCheck


Eclipse Platform

Requisite Pro RSA

Models


Eclipse Plugins API

EMF

MS Word

NuSMV

UML2

RSA View

ETCS Plugins MCFrontend RSA


Requirement fragment in the tool


Categorization of Requirements in the tool


Example: balises

2.5.1.1 Depending of the application level, the trackside sub-system can be composed of:

a) balise

2.5.1.2.1 The balise is a transmission devices that can send telegrams to the on-board sub-system.

2.5.1.2.4 The balises can provide fixed messages or, when connected to a lineside electronic unit, messages that can be changed

Other examples

Glossary

Behavior

Behavior

Behavior

Glossary


Exercise: categorizeMovement Authority, Balise group, balise, section (and

related concepts)

2.5.1.1 a (balise)2.5.1.2 (balise)

3.4.1 (balise group)

3.8.1.1 (movement authority)3.8.1.1 a (End of authority)3.8.1.1 b (LOA)3.8.1.1 f (section)3.8.2.1 (RBC - MA request)3.8.2.2 (RBC - MA request)3.8.2.5 (RBC - MA request)3.8.3.1 (section - MA)3.8.3.2 (section - MA)


Requirement Dependencies (M1.3)

Three relationships• Strong Dependency

– The requirement fragment “A” depends on the requirement fragment “B” if “A” cannot exist without “B”

• Weak Dependency

– The requirement fragment “A” depends on the requirement fragment “B” but “A” can exist without “B”

• Refinement

– The requirement fragment “A” refines the requirement fragment “B” if “A” redefines some notions of “B” at a lower level of abstraction




out stop location





An example of requirement: dependency

“In addition” as a dependency indication: strong dependency



3.8.3.2 For each section composing the Movement Authority the following information shall be given;a) Length of the sectionb) Optionally, Section time-out value and distance from beginning of section to Section Time-

out stop location

3.8.3.3 …

An example of requirement: dependency

strong dependency between 3.8.3.2 and sentences a) and b)

Glossaries

11.08 EuRailCheck


Eclipse Platform

Requisite Pro RSA

Models


Eclipse Plugins API

EMF

MS Word

NuSMV

UML2

RSA View



Exercise: dependenciesMovement Authority, Balise group, balise, section (and

related concepts)

2.5.1.1 a (balise)2.5.1.2 (balise)




M2: Formalization phaseM2.1

Model the requirements fragments

– UML

– Controlled Natural Language (CNL)

M2.2

Select a set of elements of the formalization

M2.3

Link UML elements selected in M2.2 to the requirements fragments they represent; the link is used to trace the formalization, to ease the maintenance of the formalization after updates on the requisites, to select the requisite to check directly from the Word document

=> Using Rational Software Architect, RequisitePro and the tool plug-ins


The languages

• Restricted UML 2 subset described in the OMG UML 2.X metamodel specifications*

• Extended by Controlled Natural Language (CNL)

Supported by IBM Rational tools (Rational Software Architect)

http://www.omg.org/spec/UML/2.1.2/


Why this Languages?

• Unified Modelling Language (UML)– Visual modelling as an important step in Software Engineering – De facto standard in model based design

• common in software engineering with tool support• slightly different use of some UML constructs

– (Semi)formal• very rich but unclear semantics

• Restricted use of UML– Clear semantics– Reduce complexity of translation avoiding redundancy in the

diagrams

• Use of the CNL formal language to annotate UML– Specification of properties that cannot be expressed in UML

such as time related properties


UML diagrams and constructs

• Class diagrams – E.g. to formalize the requirements that have been

categorized as “glossary” requirements

• State machines – E.g. to formalize the “behavioural” constraints

• Sequence diagrams – E.g. to represent some kind of scenarios in the

specifications


UML Class diagrams

• Classes to represent ETCS concepts (Train, RBC, …)

• Relationships to represent relevant connections among ETCS concepts – e.g., a Movement Authority has several sections associated, …

Use of class diagrams and related constructs to describe formally the ontology of the ETCS domain in the documents


UML classesA Class represents a concept (Train, Movement

Authority) in the ETCS domain

• Class attributes (attribute) – represent the set of relevant characteristics of the concept – have types {integer, real, enumerative, class_type}

Classattribute: type

…


UML classes exampleA concept in the domain: Train• Concept characteristics:

– length:real– speed:real– …

Trainlength: realspeed: real


UML classes

• Class methods (method) – represent an action the class can perform (that could be

specified via state machines or constraints)– accepts a set of parameters pari in input– a return parameter parret. – all parameters have a type defined in the set {integer, real,

enumerative, class_type}

ClassAttribute: type

method(par1:type,parn:type): parret type


UML classes exampleA concept in the domain: Train• Concept characteristics:

– length:real

– speed:real

– …

• Actions related to concepts:– start()

– send_message(m:string):boolean

Trainlength: realspeed: real

start()send_message(m:string):boolean


UML relationships

Relationships between classes represent the relation between concepts (two or more classes)

– One class is a characteristic of the other class– One class has among its characteristics an aggregation of

objects of the other class– One class represent a concept that is more abstract that the one

represented by the other


Association

Association is the basic relationship between two classes

– It can have a name

– it can be labelled via the roles (role1 and role2) of the two classes at the extremes

– It can have cardinalities (x..y and l..m) expressing the relative minimum and maximum numbers of instances of the two classes existing in the model domain

x..y l..mrole1 role2

nameclass2class1


Cardinalities• Cardinalities for the relationships represent constraints

on the number of instances of the involved classes that can be created in the domain

Multiplicities Meaning

0..1 zero or one instance

0..* or * no limit on the number of instances (including none)

1 exactly one instance

1..* at least one instance

n..m n to m instances


Association

Association is the basic relationship between two classes



– It can have cardinalities (x..y and l..m) expressing the relative minimum and maximum numbers of instances of the two classes existing in the model domain

x..y l..mrole1 role2

nameclass2class1

Train

length: realspeed: real

Driver

ID: integername: stringassignement

20..n theDriverstheTrain


UML class diagrams in ETCS


Aggregation• Aggregation: an association in which one class belongs

to a collection – It can have a name


– It can have the specification of the cardinality (x..y) expressing the relative minimum and maximum numbers of instances of the two classes existing in the model domain

x..y

role2role1

nameclass1 class2

x..y

role2role1

nameclass1 class2

1

class1

role2[x..y]: class2

class2


Example in ETCS

3.8.3.2 For each section composing the Movement Authority the …;

Mov_Auth

….

….

Section

….

….sections

a relationbetween concepts

Mov_Auth

sections[0..*]:Section

….

Section

….

….


Generalization

• Generalization/specialization: an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass


nameclass1 class2


Example in ETCS

Existence of a channel that can be specialized in a particular type of channel such as GSMR

Channel

buffer[0..*] : string

….

GSMR

error_rate : real

….

GSMR has both the characteristics



3.8.3.2 For each section composing the Movement Authority thefollowing information shall be given;a) Length of the section

3.8.3.3 In addition, the End section of the Movement Authority may include;a) …b) Danger point information (distance from end of section to danger point, release

speed related to danger point)c) Overlap information (…)

Parts of these requirements can be classified as GLOSSARY so will be codified in UML classes and relationships

An example of requirement formalization (M2.1)


Requirements 3.8.3.2 and part of 3.8.3.3

Aggregationrelationship

“simple” relationship

“generalization” relationship

Section

Length: real

….

Movement_Authority

….

….

End_Section

Overlap: real

….

Danger_Point

Distance: real

Rel_speed: real

…….Danger_point

1 1

Sections

A Class (representing

a concept) and some properties





Classes (representing



Characters to avoid

Please, in the names of attributes methods (and in general):

• avoid spaces• avoid minus signs “-”• avoid “!” and “?”• ampersand “&”

11.08 EuRailCheck


Eclipse Platform

Requisite Pro RSA

Models


Eclipse Plugins API

EMF

MS Word

NuSMV

UML2

RSA View



Formalization in the tool


Exercise: formalizeMovement Authority, Balise group, balise, section (and

related concepts)

2.5.1.1 a (balise)2.5.1.2 (balise)




UML state machines

A state machine is a graph in which the nodes represent states of a given system and the edges represent transitions between the states

Useful to describe the behavioural requirements or to describe the behaviour of the class methods

A requirement for us: we would like to maintain simple the structure of a state machine


States

• A state of the state machine is represented as a rectangle with smooth angles having a state name– Could be specified an entry condition to specify an action that

should be executed when the control flow enters in the state

State Name

entry/activity


Special states

• initial state, the first state of a state machine represented as a filled circle

• conditional state, to represent conditional branches in the state machine every one controlled by different conditions

• final state, that is the last state of a state machine

condition_1

condition_2


Transition

A Transition of a state machine the passage through states and is represented as a labelled arrow– The label of the transition is structured as [guard]/activity

State_1 State_2event[guard]/activity

event[guard]/activity


Transition

• Interpretation: – Flow is in the State_1

– When guard is true, the transition is performed together with its associated activity

– The flow enters in the State_2

• If the activity specified in the guard has to terminate before the flow could enter in the next state the name of the activity must have a “!” prefixed to the activity name (!method(par1,…,parn))

State_1 State_2event[guard]/activity

event[guard]/activity


Restrictions on the transitions labels

• Guard - [pushed_button() and console.button=start]/: – it is a set of method activations or boolean predicates involving the

variables in the model

• Activity - train.engineStart(): (or level:=2)– it is a method of the classes in the model

– or a set of simple assignments to the variables in the model (e.g., pushed:=true, …)

The same restrictions for the Activity here are also valid for the Activity in the entry condition of a state


Sequence diagrams• Diagrams that allow to describe a scenario in the domain

– e.g., the exchange of messages between train and rbc by way of a channel

2


Sequence diagrams operators

Sequence of messages can be embedded in operators that allow to specify particular message configuration

– Negation operator – Alternative operator – Parallel operator

– Option operator

– Loop operator


Option operator

• Option operator The Option (opt) operator (also called combination fragment) is used to model a sequence that, given a certain condition, will occur; otherwise, the sequence does not occur


Parallel operator

• Parallel operator The Parallel (par) operator designates a parallel merge between the behaviours of the operands. The messages of the different operands can be interleaved in any way as long as the ordering imposed by each operand as such is preserved


Loop operator

• Loop operator The loop operator will be repeated a ([minimum, maximum]) number of times specified via a guard

‘loop[‘(‘ <minint> [‘,’ <maxint> ] ‘)’]

Where: <minint> ::= non-negative natural and <maxint> ::= non-negative natural | ‘*’


Sequence diagrams vs State machines

• Use of Sequence diagrams and state machines – Sequence diagrams typically used to model the

existence of a scenario – State machines typically used to model the

universality of a scenario


Outline

• Methodology overview

• Informal Analysis

• Formalization (focus on syntax)– Restricted UML language– Controlled Natural Language (CNL)


Controlled Natural Language

• Controlled Natural Language (CNL) used to specify constraints on the elements of the models:– the “environmental” requirements

– Some kind of “behavioural” requirements (e.g., how a certain value of the attribute has to change)

– Structural constraints on class diagrams resulting from the “glossary” requirements (e.g., number of instances of a class in the model)

• The grammar for the Controlled Natural Language (CNL) for ETCS has been extracted from the definition of an existing general constraints language grammar


CNL grammarCNL grammar defines 5 types of constructs:

– INVAR, defines a constraint that is always valid – INIT, defines a constraint that is valid only initally– BEHAVIOR, defines a constraint over paths. Constraints can be

used to express situations like the change of value for a variable– SCENARIO, expresses an existential property. Is not a constraint,

but a possible behavior that we would like to have or to not have– PROPERTY, is a property that every possible admissible behavior

has to satisfy

CNL := "INIT" basic_expr | "INVAR" basic_expr | "BEHAVIOR" temporal_expr | "SCENARIO" temporal_expr | "PROPERTY" temporal_expr ;


CNL grammar (2)temporal_expr :=

basic_expr | ‘‘not’’ temporal_expr |

temporal_expr ‘‘and’’ temporal_expr | temporal_expr ‘‘or’’ temporal_expr | temporal_expr ‘‘implies’’ temporal_expr | ‘‘always’’ temporal_expr | ‘‘never’’ temporal_expr | ‘‘in the future’’ temporal_expr |temporal_expr ‘‘until’’ temporal_exprtemporal_expr ‘‘infinitely many times’’temporal_expr ‘‘will eventually hold’’ ‘‘every time’’ temporal_expr ‘‘holds,’’ temporal_expr |‘‘a sequence matching {’’ regular_expr ‘‘}’’ | quantifier_prefix temporal_expr;

Example

In the future the train will send a messagein the future (train.send(message))


CNL grammar (3)

quantifier_prefix :=

``for all'' class_name variable |

``there exists'' class_name variable ``such that'' |

``for all'' variable `ìn'' identifier_expr |

``there exists'' variable `ìn'' indentifier_expr ``such that'' |

``for all'' variable `ìn'' range_expr |

``there exists'' variable `ìn'' range_expr ``such that'' ;


CNL grammar (4)

regular_expr := basic_expr |`èmptyword'' |regular_expr ``;'' regular_expr |``{'' regular_expr ``} or {'' regular_expr ``}'' |``{'' regular_expr ``} and {'' regular_expr ``}'' |``{'' regular_expr ``}[*]'' |``{'' regular_expr ``}[*'' constant ``]'' |

``{'' regular_expr ``}[*'' constant ``..'' constant ``]''

Examples

a train can potentially send an infinite number of messages

{train.send(message)}[*]

a train can send 3 messages

{train.send(message)}[*3]


CNL: some examples

Change of value for the level

BEHAVIOR:always if level=0 then in the future level=1

A message sent (e.g., a request of Movement Authority) can be lost

SCENARIO:there exists request_MA message such that

(in the future (send(message) and never receive(message)))


CNL: some examples (2)

It is possible that the message “m” is received by the onboard subsystem “s” only after being sent three times by the RBC “r”

SCENARIO:

a sequence matching {

{

{r.send(m) and not s.receive(m)}; not s.receive(m)[*]

}[*3];

s.receive(m)

}

Two trains (train1 and train2) can never have the same position at the same time

PROPERTY:never (train1.position = train2.position)


CNL in the tool


Methodology summary

Isolation Categorization Dependency creation

Standard inspection

Informal analysis FormalizationFormal validation

Informal analysis


Methodology summary

Formal Modelling

Informal analysis FormalizationFormal validation

Formalization

Link

Documents

11.08 EuRailCheck 1 The Methodology Angelo Susi Software Engineering Unit - FBK-Irst [email protected]