Using formal methods in Industrial Software Development
1 like940 views
The document discusses the use of formal methods in software development. It provides an overview of I-Mathic, a formal method developed by Imtech that uses sequence enumeration and CSP (Communicating Sequential Processes). The document describes examples of applying I-Mathic on industrial projects, finding defects and showing high productivity. Benefits include consistent requirements and few defects, while drawbacks include limited tool integration and requiring abstract thinking. I-Mathic is currently mandated for in-house projects and continues to be developed with universities.
Using formal methods in Industrial Software Development
- 1. Using Formal Methods in Industrial Software Development European SEPG Conference London, June 2005 Robert van Lieshout, Quality Manager Robert.vanLieshout@imtech.nl 1
- 2. “Quality through Commitment and Creativity” 2
- 3. Engineering and Mathematics Every branch of Engineering uses Mathematics for Specification, Design and Verification Mechanical Engineering => Differential Equations Structural Engineering => Finite Element Analysis Circuit Engineering => Boolean Algebra, etc Except Software Engineering Originally a specialization within Mathematics! Most Software is specified and designed without using mathematics Software specifications and designs cannot be verified before implementation Software testing must find specification, design and implementation errors 3
- 4. Presentation Outline Formal Methods – then and now I-Mathic – an overview Applying I-Mathic – some results Benefits and Drawbacks Current status 4
- 5. Formal Methods Then and now 5
- 6. Formal Methods – Then ... Formal Methods have promised much and delivered little: The solution is often more complicated than the problem Formal specifications use difficult notations and require extensive mathematical background Critical Stakeholders - Business Analysts, Domain Experts and Customers - cannot understand the formal specifications Critical Stakeholders excluded from the process 6
- 7. Formal Methods – Now Growing interest in Formal Methods See: http://www.fmeurope.org/ Several methods with different objectives Proof of selected properties, rather than full correctness proof Tool support and computing power have: Reduced laboriousness Improved user-friendliness (sometimes) Made it less time consuming 7
- 8. The I-Mathic Formal Method An overview 8
- 9. I-Mathic Principles Design Principle Developers can and should strive to produce software that is nearly error free when entering testing Testing Principle The purpose of testing is quality measurement and not an attempt to “test in” quality 9
- 10. I-Mathic – Origins Used a small part of Cleanroom Sw. Eng. Sequence Enumeration Developed tool support Excel template with VB automation Scripts for visualisation Scripts for code & test generation Linked it with CSP CSP: Communicating Sequential Processes Tools to check the CSP model 10
- 13. Example Project – Assembléon AX 1..20 Pick & Place Robots PP PP PP … PP PP Run in Run out Transport system containing PCB’s 13
- 14. Example Project – AX Kernel AX Kernel GUI intf (29 states) Process Ctrl Glue intf (11 states) ‘Glue’ TERM GPE PPC GPE TC GPE SVS GPE UTL Monitor GPE intf (17 states) Module intf (10 states) 14
- 15. Example Sequence Enumeration (fragment) 0:<> 1 Cl.rqStartProduction 2 Cl.rqPauseProduction 3 Cl.rqRecover 4 Srv.ntErrorOccured 5 Srv.ntProductionStarted 6 Srv.ntProductionPaused 7 Mod.ntErrorOccured 8 Mod.ntProductionStarted 9 Mod.ntProductionPaused 1:<Cl.rqStartProduction> 10 Cl.rqStartProduction 11 Cl.rqPauseProduction 12 Cl.rqRecover 13 Srv.ntErrorOccured 14 Srv.ntProductionStarted 15 Srv.ntProductionPaused 16 Mod.ntErrorOccured 17 Mod.ntProductionStarted 18 Mod.ntProductionPaused Mod.rqStartProduction Illegal Illegal Illegal Illegal Illegal Illegal Illegal Illegal 1 - Illegal Illegal Illegal Illegal Illegal Illegal Cl.ntErrorOccured Srv.rqStartProduction Illegal 16 17 - IDLE GPE.Req1 GPE.Req2 GPE.Req3 GPE.Req1 GPE.Req2 GPE.Req3 MOD.Req1 MOD.Req2 MOD.Req3 STARTING_MOD D0 D0 D0 GPE.Req1 GPE.Req2 GPE.Req3 Module in ERROR MOD.Req1 Module in RUN state MOD.Req2 MOD.Req3 The Component Function is complete Maps every possible input sequence to response The Component is the right system Every transition rule justified, full requirements tracing Derived requirements fill the gaps 15
- 16. Results – Model Checking Model checker explores all state combinations of the CSP model ensuring that: Model is deterministic Model implements interface according to specification There are no deadlocks Finite queue size is sufficient Queues are never full (processes behave freely) 16
- 17. Results – Project Performance Size and Effort A B C 194 38 20 3000 1240 390 16050 10715 4690 Effort (man days) 112 81,5 38,5 Productivity (eLocs/man day) 143 131 122 A B C During Internal verification 5 7 5 During Acceptance 0 0 0 Post Release 3 3 0 0.2 0.3 0.0 States Transitions Code Size (eLocs) Defects Post Release Defects per 1000 eLoc 17
- 18. Example – Quick Scan Used to model part of an existing system System Characteristics: Data driven multi-media application Multi-threaded components “Mature software” Approach: Reverse-engineered models for a few scenario’s with help from domain expert Ran model checks 18
- 19. Example – Quick Scan Scope: 2 interfaces & 1 implementation modelled Interface 1: 5 states, 12 transitions Interface 2: 10 states, 39 transitions Implementation: 6 states, 44 transitions Result: Potential deadlock detected Several undocumented requirements revealed Total effort spent: <12 man days Including customer effort & writing report 19
- 20. Applying I-Mathic Benefits and Drawbacks 20
- 21. Benefits Encourages interaction with stakeholders Sufficiently understandable Consistent and complete requirements Few defects Deadlock free; No race conditions Simple defects, easy to solve High productivity Partly due to code generation Partly due to reduced test effort 21
- 22. Drawbacks Limited integration with other methods and tools I-Mathic is a very different approach Requires abstract thinking and discipline which not all software engineers have! 22
- 23. How does it scale? Current data is on relatively small projects Expected to scale well, considering the integration effort and defects Maybe next year we’ll know? 23
- 25. Current status Mandated for use in in-house projects Quick Scan Support for multi-threaded components Regular additions to toolset E.g. context sensitive menu’s Ongoing development: Research together with Dutch universities 25
- 26. References Cleanroom Software Engineering Mills, H.; Dyer, M.; & Linger, R. IEEE Software, September 1987 Communicating Sequential Processes Hoare, C.A.R. Prentice Hall, April 1985 ISBN: 0131532715 26
- 27. Thank you Any questions? Robert van Lieshout Robert.vanLieshout@imtech.nl www.imtechict.nl 27