Formal Methods in Requirements Engineering

1. Formal MethodsinRequirements Engineering CSI 5110 Fall 2005 Ali Fatolahi afato092@site.uottawa.ca

2. Requirements Engineering • Developing Tools and Methods to • Support the specification of what a Software supposed to do • In a complete, consistent and unambiguous manner • Informal Methods used usually Ali Fatolahi

3. Why Formal Methods? • Resolving Ambiguity • Completeness • Consistency • Verifiability • Modifiability • Traceability Ali Fatolahi

4. The Role in FM in RE • Different Kinds of Logic are Used • Propositional, Predicate, Temporal, Causal • Different Levels of Formalism • From Simple Models • Formal Specification and Manual Checking • Automatic Proofs • Mostly Applied in Specification Ali Fatolahi

5. Sample Practices • SIFT, NASA, 1970s • aircraft control computer • SCR, Atomic Energy, Canada, 1990 • NuSCR, South Korea, 2000s • formal software requirements specification language for nuclear power plants Ali Fatolahi

6. What I am going to do? • Taking two samples published in different years • Requirements Verification by Model Checking using Automated Tools • Using Statecharts as the Basic Model • Compare practical formal methods in requirements engineering with their original theories (As we learned in this course) Ali Fatolahi

7. An Example ofLinking Formal Methodswith CASE Tools(A Model Checker for Statecharts )The Old One!

8. Agenda of The Old One • Statecharts vs. Requirements • Are they correctly modeled? • Using formal Methods • Some Kind of Statecharts used in a Certain CASE tool (STATEMATE) • Still is in accordance with general statechart notation • UML, … Ali Fatolahi

9. Sample Statement • Uses a version of temporal logic • Starting from an initial set of configurations i, the property f eventually holds within n steps on all execution paths. • MCA n i NextConfig f Ali Fatolahi

10. Representation of MCA • MCA step iNextConfig f=de f • Let • Let MCA (step — 1) nextX NextConfig f Ali Fatolahi

11. t0:/ TEMP := VAR1 A B t1:/ VAR1 := VAR2 t2:/ VAR2 := TEMP C D Sample Program • Swap Operation Ali Fatolahi

12. Model Checking - Declaration • START • INITIAL swap cf /\ • BOOL(SemEQUAL(SemVAR 'VAR1',SemVAR 'X') cf) /\ • BOOL(SemEQUAL(SemVAR 'VAR2',SemVAR 'Y') cf) • END • BOOL(SemVAR ‘D' cf) /\ • BOOL(SemEQUAL(SemVAR 'VAR1',SemVAR ‘Y') cf) /\ • BOOL(SemEQUAL(SemVAR 'VAR2',SemVAR ‘X') cf) Ali Fatolahi

13. Model Checking - Execution • Steps 1 and 2 • 1 (2) • START • (NC swap) END swapINFO1";; 'F ' : string • Step 3 • 3 • START • (NC swap) END swapINFO1";; ‘T ' : string Ali Fatolahi

14. A FormalRequirements Engineering Method for Specification, Synthesis, and VerificationThe Young One!

15. Agenda of the Young One • Temporal Logic • Requirements Specification • Statechart • Detailed Specification • Semi-Automatic Synthesis Procedure • Logic to Statechart • Automatic Model Checking (METAFRAME) • Statechart to Logic Ali Fatolahi

16. Constraints • Local • used for single modules • using propositional logic • display and not hypertext: display /\ ~hypertext • Global • used for liveness and safety properties • using temporal logic: SLTL • Semantic Linear Temporal Logic Ali Fatolahi

17. F = :: true | type ( t ) c Ø F | F Ù F | < > F | m c F | G F Y | U SLTL Ali Fatolahi

18. User-Level SLTL Ali Fatolahi

19. Sample Application • Task • Text Processing • Requirements • Display pages 3 and 4 of a latex source in two-page format on the screen • Edit an ASCII text • Ensure that editing and compilation can run in parallel Ali Fatolahi

20. type latex_source, use two_pages, use select and finally module display Subtask 1 • Display pages 3 and 4 of a latex source in two-page format on the screen Ali Fatolahi

21. Subtask 1 type(latex_source) and (<select> true before <two_pages> true) and (finally <display> true) Ali Fatolahi

22. Subtask 1 Ali Fatolahi

23. use (<latex> true and <emacs> true) Global Property emacs and latex shall simultaneously be executable Ali Fatolahi

24. modify compile Ali Fatolahi

25. Comparison • The young one is easier to understand • The old one’s tool is more reachable • The young one is strictly dependent to a tool. • The young one is able to express more complicated cases because of using hierarchical statecharts. Ali Fatolahi

26. Conclusion • Focus of Research is on • Automated Tools for Model Checking • Because Software Engineers find Formal Methods Hard to Use • Result of Research are not Convincing yet • They do not provide enough details • Tools and Methods are far to converge • There’s an increasing interest. • But still used in critical industries. • Is it expensive? Ali Fatolahi

27. Selected References • N. Day. An example of linking formal methods with case tools: a model checker for statecharts. Proceedings of the 1993 conference of the Centre for Advanced Studies on Collaborative research: software engineering - Volume 1. Pages: 97 – 107. • von der Beeck, M.; Margaria, T.; Steffen, B.; A formal requirements engineering method for specification, synthesis, and verification. Eighth Conference on Software Engineering Environments. 8-9 April 1997 Page(s):131 – 144. • A Formal Software Requirements Specification Method for Digital Nuclear Plants Protection Systems. Junbeom Yoo, Taihyo Kim, Sungdeok Cha, Jang-Su Lee, Han Seong Son. 2005 Journal of Systems and Software, Vol.74, No.1, pp73-83. • www.ilogix.com • Jeremy T. Lanman. Using Formal Methods in Requirements Engineering, Version 1.0.Department of Computing and Mathematics, Embry-Riddle Aeronautical University. Technical Report 18 Nov 2002. Ali Fatolahi