1 / 74

The Methodology

The Methodology. Angelo Susi Software Engineering Unit - FBK-Irst susi@fbk.eu. 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

zanna
Télécharger la présentation

The Methodology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Methodology Angelo Susi Software Engineering Unit - FBK-Irst susi@fbk.eu 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 EuRailCheck

  3. ETCS: notes on the project 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! 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 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 EuRailCheck

  7. From Informal to Formal NATURAL LANGUAGE SEMIFORMAL LANGUAGE FORMAL LANGUAGE 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 EuRailCheck

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

  10. Management of natural language specifications • 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 EuRailCheck

  11. M1: Informal Analysis Phase M1.1 isolation of the fragments that identify basic units of the domain requirements document M1.2 categorizationof 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 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) EuRailCheck

  13. Checklist EuRailCheck

  14. An example of requirement 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 section 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 section b) Danger point information (distance from end of section to danger point, release speed related to danger point) 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) EuRailCheck

  15. An example of requirement isolation and categorization 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 section 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-outvalue 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) 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” EuRailCheck

  16. An example of requirement isolation and categorization 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 section 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 section b) Danger point information (distance from end of section to danger point, release speed related to danger point) 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” EuRailCheck

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

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

  19. Requirement fragment in the tool EuRailCheck

  20. Categorization of Requirements in the tool EuRailCheck

  21. Glossary Glossary Behavior Behavior Behavior Other examples 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 EuRailCheck

  22. Exercise: categorize Movement 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) 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 EuRailCheck

  24. An example of requirement: dependency 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 section 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 section b) Danger point information (distance from end of section to danger point, release speed related to danger point) 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) “In addition” as a dependency indication: strong dependency EuRailCheck

  25. An example of requirement: dependency 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 section Optionally, Section time-out value and distance from beginning of section to Section Time-out stop location 3.8.3.3 … Glossaries strong dependency between 3.8.3.2 and sentences a) and b) EuRailCheck

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

  27. Exercise: dependencies Movement 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) 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 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/ 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 beexpressed in UML such as time related properties 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 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 EuRailCheck

  33. Class attribute: type … 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} EuRailCheck

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

  35. Class Attribute: type method(par1:type,parn:type): parret type 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 parameterspari in input • a return parameterparret. • all parameters have a type defined in the set {integer, real, enumerative, class_type} 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 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 EuRailCheck

  38. x..y role1 role2 l..m class1 class2 name 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 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 EuRailCheck

  40. Train Driver theDrivers theTrain 0..n x..y role1 role2 2 l..m class1 class2 length: real speed: real ID: integer name: string name assignement 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 EuRailCheck

  41. UML class diagrams in ETCS EuRailCheck

  42. name x..y 1 class1 class2 role1 role2 class1 role2[x..y]: class2 name x..y class1 class2 class2 role1 role2 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 EuRailCheck

  43. a relation between concepts Mov_Auth Section …. …. sections …. …. Section Mov_Auth …. sections[0..*]:Section …. …. Example in ETCS 3.8.3.2 For each section composing the Movement Authority the …; 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 class1 class2 name EuRailCheck

  45. Channel buffer[0..*] : string …. GSMR error_rate : real …. Example in ETCS Existence of a channel that can be specialized in a particular type of channel such as GSMR GSMR has both the characteristics EuRailCheck

  46. An example of requirement formalization (M2.1) Example from the Movement Authority section of the Specifications 3.8.3.2 For each sectioncomposing the Movement Authority the following information shall be given; a) Length of the section 3.8.3.3 In addition, the End section of the Movement Authority mayinclude; a) … b) Danger point information (distance from end of section to danger point,release speed related to danger point) Overlap information (…) Parts of these requirements can be classified as GLOSSARY so will be codified in UML classes and relationships EuRailCheck

  47. Section Movement_Authority Length: real …. Sections …. …. A Class (representing a concept) and some properties A Class (representing a concept) and some properties Classes (representing a concept) and some properties A Class (representing a concept) and some properties End_Section Danger_Point Overlap: real Distance: real Rel_speed: real 1 1 …. ……. Danger_point Requirements 3.8.3.2 and part of 3.8.3.3 Aggregation relationship “generalization” relationship “simple” relationship EuRailCheck

  48. Characters to avoid Please, in the names of attributes methods (and in general): • avoid spaces • avoid minus signs “-” • avoid “!” and “?” • ampersand “&” EuRailCheck

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

  50. Formalization in the tool EuRailCheck

More Related