Agile Formal Method Engineering

1
Agile Formal Method Engineering

• Richard Paige and Phil Brooke
• paige_at_cs.york.ac.uk, p.j.brooke_at_tees.ac.uk
• Department of Computer Science, University of
  York, UK.
• School of Computing, University of Teesside, UK.

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 cant fully anticipate requirements for a
  method, and even if you could up front, theyre
  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 dont (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?
• Lets 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? Whats a
  good method increment?
• These are domain dependent.
• XP doesnt 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 its 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.