AADL Requirements Annex Review

Transcription

1 Dominique Blouin Lab-STICC Université de Bretagne-Occidentale Université de Bretagne-Sud Bretagne, France 1 AADL Standards Meeting, April 23 th, 2013

2 Agenda Comments from Annex Document Review Motivations for a Requirements Annex Requirements Annex Overview Remaining Work Future Plans 2

3 Agenda Comments from Annex Document Review Motivations for a Requirements Annex Requirements Annex Overview Remaining Work Future Plans 3

4 Motivations for a Requirements Annex RDAL RDAL + AADL + SAVI Benefits of early fault discovering (Feiler 2009) 4

5 Why a New RE Language? Existing languages: URN (ITU Z.151) GRL UCM 5

6 Problems with Existing RE Languages Include constructs for both the problem (requirements) and solution (design) domains. Implies duplication of information. Model transformation used to derive an initial AADL design. Need for model synchronization. Difficult to trace requirements to AADL design elements. Not always adapted to support RE bests practices of embedded systems development. 6

7 FAA REMH David Lempia and Steven Miller Rockwell Collins Set of best practices to enable successful management of requirements. Based on a study of the literature and industry practices. David Lempia and Steven Miller Rockwell Collins Methods and tools from research not adopted because of the difficulty to change existing practices and tools. REMH proposes a set of 11 practices that can be adopted incrementally. 7

8 Objectives for Requirements Annex Separate the concerns: Problem (requirements) / solution (design) Easy to use with AADL (and potentially other ADLs). Emphasis on semantics: Analysis Partially automated validation of requirements specifications. Automated verification of formally expressed requirements. Documentation generation Requirements spec. generated from the model (not the reverse). Fitted for the embedded systems domain. 8

9 Objectives for Requirements Annex Extensible with respect to: Expression languages (natural, OCL, Lute, PSL, BLESS, etc.). Traceability (traceability links to models from other languages for different concerns can be defined) Incorporate good ideas from other languages and methods: SysML KAOS URN FAA Requirements Engineering Management Handbook Do not restrict the use of the language to a specific process. 9

10 Agenda Comments from Annex Document Review Motivations for a Requirements Annex Requirements Annex Overview Remaining Work Future Plans 10

11 How the Annex is Presented Introduce the concepts with class diagrams. Show usage examples with parts of the FAA isolette thermostat example modeled with RDAL and AADL. 11

12 Class Diagram Conventions Reference (blue) Inheritance (black) Language Color Legend 12

13 FAA Isolette Thermostat Example Two functions introduced for safety reasons: Maintain constant current temperature. Monitor current temperature. 13

14 Modeling of the Example RDAL Meta- Model AADL Meta- Model <<conforms to>> URN Meta- Model <<conforms to>> <<conforms to>> <<conforms to>> <<traced to>> RDAL RDAL Model RDAL Model Model URN URN Model URN Model Model <<traced to>> AADL AADL Model AADL Model Model Settings Model Settings Meta-Model 15

15 Core RDAL Language 16

16 Contractual Element Realizations 17

17 Organizational Elements 18

18 Refinement Elements Inspired from KAOS refinement mechanism. Used to model: Decomposition into sub-requirements providing more details. Design alternatives. Example KAOS diagram. 19

19 Refinement Elements A section was added to SAE document on refinements. Additional weight property on decomposition. Reviewed so that refined elements are independent of their refining elements. Allows sending a high level requirements specification without the need to send all its refinements. 20

20 Allocation of System Requirements to Subsystems 21

21 System Overview Definition The system interacts with its environment through variables (monitored / controlled). System requirements define a precise relationship between monitored and controlled variables for all contexts of operation of the system. System Boundary == Environment Variables. Getting the system boundary correct is 90 % of the problem! Stuart Faulk to Steven Miller 22

22 System Overview Definition 23

23 System Overview Definition Combined RDAL and AADL to formalize the system overview. Profiled AADL for defining the system overview. RDAL to represent system overview concepts and trace AADL elements. 24

24 System Context Definition Normal context of operation. 25

25 AADL System Overview Specification 26

26 Requirements Capture 27

27 Graphical Tool Support Graphical and Textual (to be defined) syntaxes. 28

28 Requirements Expressions Libraries Choice of constraint languages Expression Extensible Choice of Constraint Languages 29

29 Scope of Expressions The expressions attached to requirements, assumptions and goals are evaluated in the context of the associated design elements. A scope must be provided for constructs such as: Lute: predefined sets such as Processor_Set, etc. OCL: allinstance The scope is taken as the elements contained in the design elements of the requirements specification. Includes elements from the with clauses. 30

30 Example Pacemaker Scope 31

31 Traceability to Use Case Steps 32

32 Environmental Assumptions Environmental assumptions constrain the entities of the environment. Having a formalized system boundary allow to distinguish between assumptions and requirements. Allows checking that an assumption on an entity has a corresponding requirement in the requirements specification of the entity. 33

33 Environmental Assumptions 34

34 Image Requirements in Isolette Specification 35

35 Goal Capture The definition of requirements and goals greatly varies in languages. Often there is a distinction between: Functional Non-functional. RDAL: Requirements: Verifiable (binary). Goals: Satisfiable to a level (quantitative). 36

36 Goals Capture 37

37 Like requirements, goals can be: Refined. Bridged to design elements. Goal Capture Expressed formally (returning a value of the satisfaction level). Linked to non-functional properties and sensitivity points for design optimization. Ongoing work with Etienne Borde, Greg Loniewsky and Emilio Insfran. 38

38 Traceability to Use Cases 39

39 Bridge to Design Elements 40

40 Hard / Soft Bridges to Design Elements A soft bridge provides a view of the design for assigning requirements and goals to design elements. The bridged elements must be part of the scope of the specification. Hard (Direct Reference) Soft (Query Expression) 41

41 Constraints Languages ML Declare constraints languages in an opaque manner. Extensible (can easily add new languages). Used by other tools (Open-PEOPLE quantitative analysis framework). 42

42 Settings Declares typing rules for RDAL generic traceability points per target language. Declares user-defined hierarchical categories for various RDAL elements: Requirements, Assumptions, Goals and Verification Activities. 43

43 Revised Settings Meta-Model Traceability Typing Rules Userdefined Categories

44 Semantics (Quality Assurance of Requirements Specification) A requirements specification allows to differentiate an acceptable from a not acceptable system. Acceptable: All requirements of the specification are verified by the system. Not acceptable: At least one requirement of the specification is not verified. Precondition: The requirements specification is itself acceptable. 45

45 Semantics (Quality Assurance of Requirements Specification) Characteristics of a good requirements specification (IEEE Std ) Correct Unambiguous Complete Consistent Ranked for importance and/or stability Verifiable Modifiable Traceable No intent to proof correct requirements specification, but several simple analyses can help finding errors. 46

46 Semantics (Requirements Specification Alone) Correct: Every requirement is one that the software shall meet. RDAL Analysis: Verify that contracts represent a stakeholder need. Every requirement and goal must be linked to a Stakeholder, considering refinements and derivations. Verify that there is rationale for contracts. Every requirement, goal and assumption are linked to a Rationale element. Every rationale is linked to a stakeholder of the contract. 47

47 Semantics (RDAL + AADL Specification) Requirements visibility: Following AADL property visibility mechanism: *From SAE AS5506 AADL Specification 48

48 Semantics (RDAL + AADL Specification) Automated verification of requirements. Automated satisfaction evaluation of goals. Support for goal-driven design optimization. 49

49 Semantics (RDAL + AADL Specifications) Validation of integration of multi-team (subcontractors) design models: Verification of environmental assumptions on the global system overview model (thanks to formal identification of the system boundary). Verification of image requirements and assumptions. 50

50 Agenda Comments from Annex Document Review Motivations for a Requirements Annex Requirements Annex Overview Remaining Work Future Plans 51

51 Remaining Work on Language Define a textual syntax. Would KSU be working on it? Complete the definition of the graphical syntax. Add means to define user properties (like in ReqIF). Rename Contractual Element to Agreed Element? Specialize Requirement class into functional / non-functional like for goals?

52 Remaining Work on Language Are system function goals really needed? Used to model preliminary system goals of the isolette example. Could be represented as high level requirements expressed in natural language. Or allow refining system function goals into requirements? Review traceability mechanism between requirements and design? Right now, traceability goes from requirements models to design models. Usually it is the reverse so that several designs can tentatively meet the same requirements specification. However, alternatives are represented in the requirements specification through refinements. Besides, we need a scope for evaluating the requirements expressions. Currently provided by the design elements of the specification.

53 Remaining Work on RDALTE1 Fix the reference to AADL models elements problem. OSATE instance model has the same problem Study this problem and RDAL traceability issues in the context of Global Model Management (GMM). GMM introduced in the next presentation.

54 Remaining Work on RDALTE2 Implement textual syntax (Xtext based). Update the graphical editor for latest RDAL. Implement meta-model constraints. Implement analyses. Quality assurance of requirements specification. Implement requirements visibility mechanism. Improve implementation of automated verification of requirements. Adapt advanced editor view to define requirement condition.

55 Remaining Work on RDALTE2 Experiment with a behavioral constraint language. Integration of BLESS? System overview editor: Option 1: Finish developing the Graphiti editor. Option 2: Implement a profiling mechanism in the Adele editor. Option 2 could allow implementing other editors such as data flow diagrams to represent system functions with AADL.

56 Agenda Comments from Annex Document Review Motivations for a Requirements Annex Requirements Annex Overview Remaining Work Future Plans 57

57 Future Plans The funding for this work (Open-PEOPLE project) ended in December I will not have much time to work on the project until the end of the Adele joint project. Expected to finish end of October How could we continue this project in the longer term? Any ideas for funding?