11.08 EuRailCheck 1 The Methodology Angelo Susi Software Engineering Unit - FBK-Irst [email protected].
-
Upload
elijah-klein -
Category
Documents
-
view
222 -
download
0
Transcript of 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
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
11.08 EuRailCheck 11
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
11.08 EuRailCheck 12
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)
11.08 EuRailCheck 13
Checklist
11.08 EuRailCheck 14
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
11.08 EuRailCheck 15
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)
Fragments of these requirements can be classified as “glossary”
An example of requirement isolation and categorization
11.08 EuRailCheck 16
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)
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
Tool SW Architecture
Eclipse Platform
Requisite Pro RSA
Models
Rational Software Architect
Eclipse Plugins API
EMF
MS Word
NuSMV
UML2
RSA View
ETCS Plugins MCFrontend RSA
11.08 EuRailCheck 19
Requirement fragment in the tool
11.08 EuRailCheck 20
Categorization of Requirements in the tool
11.08 EuRailCheck 21
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
11.08 EuRailCheck 22
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)
11.08 EuRailCheck 23
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
11.08 EuRailCheck 24
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: dependency
“In addition” as a dependency indication: strong dependency
11.08 EuRailCheck 25
Example from the Movement Authority section of the Specifications
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
Tool SW Architecture
Eclipse Platform
Requisite Pro RSA
Models
Rational Software Architect
Eclipse Plugins API
EMF
MS Word
NuSMV
UML2
RSA View
ETCS Plugins MCFrontend
11.08 EuRailCheck 27
Exercise: dependenciesMovement 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)
11.08 EuRailCheck 28
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
11.08 EuRailCheck 29
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/
11.08 EuRailCheck 30
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
11.08 EuRailCheck 31
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
11.08 EuRailCheck 32
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
11.08 EuRailCheck 33
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
…
11.08 EuRailCheck 34
UML classes exampleA concept in the domain: Train• Concept characteristics:
– length:real– speed:real– …
Trainlength: realspeed: real
11.08 EuRailCheck 35
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
11.08 EuRailCheck 36
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
11.08 EuRailCheck 37
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
11.08 EuRailCheck 38
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
11.08 EuRailCheck 39
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
11.08 EuRailCheck 40
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
Train
length: realspeed: real
Driver
ID: integername: stringassignement
20..n theDriverstheTrain
11.08 EuRailCheck 41
UML class diagrams in ETCS
11.08 EuRailCheck 42
Aggregation• Aggregation: an association in which one class belongs
to a collection – 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 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
11.08 EuRailCheck 43
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
….
….
11.08 EuRailCheck 44
Generalization
• Generalization/specialization: an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass
– It can have a name
nameclass1 class2
11.08 EuRailCheck 45
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
11.08 EuRailCheck 46
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 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)
11.08 EuRailCheck 47
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
A Class (representing
a concept) and some properties
A Class (representing
a concept) and some properties
Classes (representing
a concept) and some properties
11.08 EuRailCheck 48
Characters to avoid
Please, in the names of attributes methods (and in general):
• avoid spaces• avoid minus signs “-”• avoid “!” and “?”• ampersand “&”
11.08 EuRailCheck
Tool SW Architecture
Eclipse Platform
Requisite Pro RSA
Models
Rational Software Architect
Eclipse Plugins API
EMF
MS Word
NuSMV
UML2
RSA View
ETCS Plugins MCFrontend
11.08 EuRailCheck 50
Formalization in the tool
11.08 EuRailCheck 51
Exercise: formalizeMovement 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)
11.08 EuRailCheck 52
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
11.08 EuRailCheck 53
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
11.08 EuRailCheck 54
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
11.08 EuRailCheck 55
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
11.08 EuRailCheck 56
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
11.08 EuRailCheck 57
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
11.08 EuRailCheck 58
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
11.08 EuRailCheck 59
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
11.08 EuRailCheck 60
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
11.08 EuRailCheck 61
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
11.08 EuRailCheck 62
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 | ‘*’
11.08 EuRailCheck 63
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
11.08 EuRailCheck 64
Outline
• Methodology overview
• Informal Analysis
• Formalization (focus on syntax)– Restricted UML language– Controlled Natural Language (CNL)
11.08 EuRailCheck 65
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
11.08 EuRailCheck 66
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 ;
11.08 EuRailCheck 67
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))
11.08 EuRailCheck 68
CNL grammar (3)
quantifier_prefix :=
``for all'' class_name variable |
``there exists'' class_name variable ``such that'' |
``for all'' variable ``in'' identifier_expr |
``there exists'' variable ``in'' indentifier_expr ``such that'' |
``for all'' variable ``in'' range_expr |
``there exists'' variable ``in'' range_expr ``such that'' ;
11.08 EuRailCheck 69
CNL grammar (4)
regular_expr := basic_expr |``emptyword'' |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]
11.08 EuRailCheck 70
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)))
11.08 EuRailCheck 71
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)
11.08 EuRailCheck 72
CNL in the tool
11.08 EuRailCheck 73
Methodology summary
Isolation Categorization Dependency creation
Standard inspection
Informal analysis FormalizationFormal validation
Informal analysis
11.08 EuRailCheck 74
Methodology summary
Formal Modelling
Informal analysis FormalizationFormal validation
Formalization
Link