Presentation is loading. Please wait.

Presentation is loading. Please wait.

11.08 EuRailCheck 1 The Methodology Angelo Susi Software Engineering Unit - FBK-Irst

Similar presentations


Presentation on theme: "11.08 EuRailCheck 1 The Methodology Angelo Susi Software Engineering Unit - FBK-Irst"— Presentation transcript:

1 11.08 EuRailCheck 1 The Methodology Angelo Susi Software Engineering Unit - FBK-Irst

2 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

3 11.08 EuRailCheck 3 ETCS: notes on the project

4 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!

5 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

6 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

7 11.08 EuRailCheck 7 From Informal to Formal NATURAL LANGUAGE SEMIFORMAL LANGUAGE FORMAL LANGUAGE

8 11.08 EuRailCheck 8 Steps of the methodology M1Informal analysis phase: –categorization and structuring of the informal requirements fragments described in the requirements document to produce categorized requirement fragments M2Formalization 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 M3Formal validation phase: –identification of a subset of the formalized requirement fragments –definition of the validation problems –automatic validation analysis

9 11.08 EuRailCheck M1 (Requirement categorization and Structuring) via Requisite Pro M2 (Requirements Formalization) via Rational Software Architect M3 (Problem Definition) via RSA plug-in Interpretation of MC Results M3 (Model Checking) via NuSMV

10 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 11.08 EuRailCheck 11 M1: Informal Analysis Phase M1.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

12 11.08 EuRailCheck 12 Categories of requirement fragments (M1.1-M1.2) The categories are also used to guide the formalization in M2 by suggesting to use a particular language construct (UML element/CNL constraint)

13 11.08 EuRailCheck 13 Checklist

14 11.08 EuRailCheck 14 Example from the Movement Authority section of the Specifications For each section composing the Movement Authority the following information shall be given; a)Length of the section b)Optionally, Section time-out value and distance from beginning of section to Section Time- out stop location 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 section b)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

15 11.08 EuRailCheck 15 Example from the Movement Authority section of the Specifications For each section composing the Movement Authority the following information shall be given; a)Length of the section b)Optionally, Section time-out value and distance from beginning of section to Section Time- out stop location 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 section b)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

16 11.08 EuRailCheck 16 Example from the Movement Authority section of the Specifications For each section composing the Movement Authority the following information shall be given; a)Length of the section b)Optionally, Section time-out value and distance from beginning of section to Section Time- out stop location 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 section b)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

17 11.08 EuRailCheck Eclipse Platform Requisite Pro RSA Models Rational Software Architect Eclipse Plugins API EMF MS Word NuSMV UML2 RSA View ETCS Plugins MC Frontend Tool SW Architecture RSA

18 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 MC Frontend RSA

19 11.08 EuRailCheck 19 Requirement fragment in the tool

20 11.08 EuRailCheck 20 Categorization of Requirements in the tool

21 11.08 EuRailCheck 21 Example: balises Depending of the application level, the trackside sub-system can be composed of: a) balise The balise is a transmission devices that can send telegrams to the on- board sub-system The balises can provide fixed messages or, when connected to a lineside electronic unit, messages that can be changed Other examples Glossary Behavior Glossary

22 11.08 EuRailCheck 22 Exercise: categorize Movement Authority, Balise group, balise, section (and related concepts) a (balise) (balise) (balise group) (movement authority) a (End of authority) b (LOA) f (section) (RBC - MA request) (RBC - MA request) (RBC - MA request) (section - MA) (section - MA)

23 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

24 11.08 EuRailCheck 24 Example from the Movement Authority section of the Specifications For each section composing the Movement Authority the following information shall be given; a)Length of the section b)Optionally, Section time-out value and distance from beginning of section to Section Time- out stop location 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 section b)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

25 11.08 EuRailCheck 25 Example from the Movement Authority section of the Specifications For each section composing the Movement Authority the following information shall be given; a)Length of the section b)Optionally, Section time-out value and distance from beginning of section to Section Time- out stop location … An example of requirement: dependency strong dependency between and sentences a) and b) Glossaries

26 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 MC Frontend

27 11.08 EuRailCheck 27 Exercise: dependencies Movement Authority, Balise group, balise, section (and related concepts) a (balise) (balise) (balise group) (movement authority) a (End of authority) b (LOA) f (section) (RBC - MA request) (RBC - MA request) (RBC - MA request) (section - MA) (section - MA)

28 11.08 EuRailCheck 28 M2: Formalization phase M2.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

29 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/

30 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

31 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

32 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

33 11.08 EuRailCheck 33 UML classes A 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} Class attribute: type …

34 11.08 EuRailCheck 34 UML classes example A concept in the domain: Train Concept characteristics: –length:real –speed:real –… Train length: real speed: real

35 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 par i in input –a return parameter par ret. –all parameters have a type defined in the set {integer, real, enumerative, class_type} Class Attribute: type method(par 1 :type,par n :type): par ret type

36 11.08 EuRailCheck 36 UML classes example A concept in the domain: Train Concept characteristics: –length:real –speed:real –… Actions related to concepts: –start() –send_message(m:string):boolean Train length: real speed: real start() send_message(m:string):boolean

37 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

38 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 (role 1 and role 2 ) 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..yl..mrole 1 role 2 name class 2 class 1

39 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 MultiplicitiesMeaning 0..1zero or one instance 0..* or *no limit on the number of instances (including none) 1exactly one instance 1..*at least one instance n..mn to m instances

40 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 (role 1 and role 2 ) 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..yl..mrole 1 role 2 name class 2 class 1 Train length: real speed: real Driver ID: integer name: string assignement 2 0..n theDrivers theTrain

41 11.08 EuRailCheck 41 UML class diagrams in ETCS

42 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 (role 1 and role 2 ) 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 name class 1 class 2 x..y role2role1 name class 1 class 2 1 class 1 role 2 [x..y]: class 2 class 2

43 11.08 EuRailCheck 43 Example in ETCS For each section composing the Movement Authority the …; Mov_Auth …. Section …. sections a relation between concepts Mov_Auth sections[0..*]:Section …. Section ….

44 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 name class 1 class 2

45 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

46 11.08 EuRailCheck 46 Example from the Movement Authority section of the Specifications For each section composing the Movement Authority the following information shall be given; a)Length of the section 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)

47 11.08 EuRailCheck 47 Requirements and part of Aggregation relationship 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

48 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 &

49 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 MC Frontend

50 11.08 EuRailCheck 50 Formalization in the tool

51 11.08 EuRailCheck 51 Exercise: formalize Movement Authority, Balise group, balise, section (and related concepts) a (balise) (balise) (balise group) (movement authority) a (End of authority) b (LOA) f (section) (RBC - MA request) (RBC - MA request) (RBC - MA request) (section - MA) (section - MA)

52 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

53 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

54 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

55 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_1State_2 event[guard]/activity

56 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(par 1,…,par n )) State_1State_2 event[guard]/activity

57 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

58 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

59 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

60 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

61 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

62 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[( [, ] )] Where: ::= non-negative natural and ::= non-negative natural | *

63 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

64 11.08 EuRailCheck 64 Outline Methodology overview Informal Analysis Formalization (focus on syntax) –Restricted UML language –Controlled Natural Language (CNL)

65 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

66 11.08 EuRailCheck 66 CNL grammar CNL 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 ;

67 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_expr temporal_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 message in the future (train.send(message))

68 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'' ;

69 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]

70 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)))

71 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)

72 11.08 EuRailCheck 72 CNL in the tool

73 11.08 EuRailCheck 73 Methodology summary Isolation Categorization Dependency creation Standard inspection Informal analysisFormalization Formal validation Informal analysis

74 11.08 EuRailCheck 74 Methodology summary Formal Modelling Informal analysisFormalization Formal validation Formalization Link


Download ppt "11.08 EuRailCheck 1 The Methodology Angelo Susi Software Engineering Unit - FBK-Irst"

Similar presentations


Ads by Google