Agile Formal Method Engineering

1. Richard Paige and Phil Brooke paige@cs.york.ac.uk, p.j.brooke@tees.ac.uk Department of Computer Science, University of York, UK. School of Computing, University of Teesside, UK. Agile Formal Method Engineering

2. Background & Motivation • How do we build software development methods? • Whether we are constructing new ones, or integrating them? • But what are the best practices and principles for building/integrating methods? • Based on, e.g., the many examples we have of combining languages, integrating methods, etc., from the IFM community? • Is there a process that we can follow?

3. The Reality • Methods are not static constructs. • They are usually tailored when development starts. • Process phases are discarded or added. • Tool support is developed/bought which has knock-on effects. • Notations/languages are extended or restricted (e.g., UML). • Measurement/management tasks are aligned with technical tasks. • Our initial requirements for a development method will not match what is required 10 weeks into the project. • What developers need to use may change. • What managers require of developers may also change. • We should anticipate that our requirements for a method may change, even while the method is being used.

4. Premise • A software development method is like a software product. • This phrase is deliberately chosen (discussed later). • It can be built, has quality attributes, and its users have functional and non-functional requirements for it. • If we can systematically build software, we can systematically build a software development method. • Work on process modelling (e.g., SPEM), process meta-models and process patterns (e.g., Ambler, Coplien), MDA components also take this view. • We take a contrasting, though compatible view: • You can’t fully anticipate requirements for a method, and even if you could up front, they’re going to change. • We need to be agile in constructing software development methods.

5. What Do We Mean by Agile? • The Agile Manifesto (www.agilemanifesto.org) is a set of guiding values and principles that have been shown to be valuable in software development. • There is an emphasis on team-work and involving the customer in development. • There is an expectation that requirements will change, and this should influence how we design software. • There is an emphasis on doing the simplest thing that will work now, rather than on trying to anticipate the uncertain future. • These are principles, not rules - individual and team judgment must always play a role.

6. Some Example Principles • Satisfy the customer through early and continuous delivery of working software. • Welcome changing requirements, even late in the development process. • Deliver working software frequently. • Business people and developers must work together. • Simplicity - the art of maximizing the amount of work not done - is essential. • Working software is the primary measure of progress.

7. Agile Methods • Agile methods take these principles and generally try to implement them using concrete practices. • Example: Extreme Programming. • Planning game: quickly determine the scope of the next release using business priorities and technical estimates. • Testing: developers write unit tests which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished. • Collective ownership: anyone can change any code anywhere in the system at any time. • Pair programming: all production code is written with two programmers at one machine. • ... • Lots of other agile methods exist, e.g., FDD, TDD, Scrum, Crystal, Agile Modelling...

8. Agile Construction of Methods • Agile principles & practices can be used to deliver working methods to customers. • delivery includes documentation, languages, tools, process. • Similarities between software and methods: • Methods have behaviour and can be tailored. • Methods have descriptions (e.g., a user manual). • Methods require experts to tailor and extend. • Differences between software products and methods: • Software products come with an executable description; methods generally don’t (though see MDA components) • We can tell when a software product is well-formed (it compiles and executes); when is a method well-formed? • Software has dimensions (e.g., KLOC, MTBF).

9. Using Agile Techniques to Build Methods • Agile Method Development can happen in parallel with Software Development. • Ostensibly it should happen in this way. • We need feedback about how well the method meets its requirements. • Thus in Agile Method Development we view the method as something that evolves from real application. • How do principles from Agile Manifesto apply to building methods? • An agile method for building methods. • Examples: SCOOP + CSP, MOF Action Semantics.

10. Agile Manifesto of Building Methods • Many of the principles apply directly: • “Welcome changing requirements”: we should anticipate that our methods will change during development • Customers may request “refactorings”, e.g., new process phases, new notations or languages, to be added. • “Deliver working methods frequently”: the first version of a new method should be available quickly - days or a couple of weeks rather than months - for customers to try it out. • “Working methods are the only measure of success”: thus the method must be developed while it is being used by real software developers. • “Simplicity is essential”: build the simplest method that works now. • ... lots more in the paper • “Self-organizing teams”: not clear how essential this is for method developers.

11. Agile Method Development • So how do we implement these principles? • Let’s be agile! • A simple method for method development (cf. TDD, FDD): • Construct user stories, i.e., how developers would like to use the new method. • Prioritise the stories. • Deliver a method increment that satisfies the highest-priority stories. • Iterative/incremental. • A method increment goes some way towards satisfying user stories. • How do we describe a method increment? What’s a good method increment? • These are domain dependent. • XP doesn’t say how you should describe your software. • But XP/TDD do help you to measure success (your tests pass). • The only analogy of this in method development will be customer success and positive feedback.

12. Case Study • Details in the paper. • Integrating Simple Concurrent Object-Oriented Programming (SCOOP) extension to Eiffel with CSP. • Not just a language integration, but process/tools as well. • Initial motivation: soundness of SCOOP. • Theoretically: it’s a complex concurrency model with a precise, yet informal semantics. • Practically: industrial interest to get a working compiler. • Efforts in parallel with development of prototype of SCOOP and evolution of the standard.

13. First User Story • Customer: “We want to be able to reason, formally, about the semantics of SCOOP programs.” • Lots of uncertainty here: • What sort of reasoning? Automated? Semi-automated? What types of properties are interesting? • All SCOOP programs? Are some more important than others? • Negotiation with users to refine this initial story. • Customer: “For any SCOOP program we would like to be able to extract its concurrent behaviour in isolation, and reason – ideally with tool support – about the behaviour of routine calls. In particular, we would like to be able to reason about the behaviour of routine calls in the presence of contracts, but also would like to be able to reason about object reservations and lazy evaluation.”

14. Iterations Deliverables: • Model • FDR2 program • process for going from SCOOP to FDR2 • design decisions

15. MOF Action Semantics • Case study not discussed in paper. • Customer: “Extend Meta-Object Facility (MOF) and its supporting tools to capture behaviour.” • Motivation for this was to improve consistency checking of MOF-based languages, such as UML. • Initial set of requirements: • Need to capture actions, and do intra-model consistency checking (eg., between class and communication diagrams) • Iteration 1 produced a partial semantics and a partial implementation using UML2MOF. • Refined requirements then asked for coverage of events and object lifecycles, as well as standalone tool support. • Iteration 2 produced a semantics, navigation language, and consistency checking tool, as well as a process to use them.

16. Conclusions • Build your methods with their intended users in mind. • Better yet – build your methods in collaboration with your users. • Ideally in a way that allows detailed feedback to be obtained while the method is being used in anger. • You can be agile if your users are a willing participant in the development of your method (easier said than done). • The approach is realistic and cost effective. • We produced the MOF AS to extremely tight deadline (~ 3 weeks) • Developed the SCOOP-CSP integration within a few weeks as well (without a Sword of Damocles) • A key question: ‘success criteria’ for a method – i.e., what are the equivalents of unit tests in agile method engineering? • Strawman examples, e.g., in MDD everyone does the Pet Store or Library? • User feedback.

17. Method Increments • The method evolves as new user stories are implemented in a method description. • Each method increment may involve adding new notations, adding process phases, modifying phases, delivering new tools, etc. • Change requirements may come from developers as they use the method. • Will lead to new user stories and re-prioritisation. • Not all user stories need be implemented by method developers in order for users to achieve success. • Basically, this approach builds the smallest, simplest method that supports the developers understanding of their requirements at this moment.