UML-RSDS: A tool to support agile model-based development using UML

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

Kevin Lano presents his recent work (and new book) on UML-RSDS, a tool to support agile model-based development with UML. Enjoy!

Many attempts have been made to combine agile development and model-based development (MBD). Executable UML (xUML) and the fUML/Alf subsets of UML are one possible basis for this combination, with developers focussing their work on UML models instead of on code. Other UML-based approaches have also been used, such as Motorola’s MDD-SLAP method combining MDD and Scrum for telecoms system development. A major hindrance to the agility of UML-based methods is the use of multiple inter-related UML models (such as class diagrams, state machines, sequence diagrams, activities, etc) to define different views of a system. Revisions to one model usually imply the need to change other models in order to preserve inter-model consistency, and the rapid iterations needed for agility become difficult to achieve. At the other extreme, very minimal modelling languages, such as XML, have been used successfully for agile MBD, but in narrow domains such as particular web application technologies.

Over 20 years, we have evolved an approach to rapid system specification and synthesis, UML-RSDS, which uses a small subset of UML (use cases, class diagrams and OCL) to precisely specify systems at a high level of abstraction. Activities (pseudocode) may also be used to define a design level for a system — although in most cases such a design description can be automatically synthesised from the specification.

For example, a use case findCouples which finds all pairs of actors/actresses who have been in at least three common movies in the international movie database could be specified by a single OCL postcondition:

p : Person & q : Person & p /= q & comm = p.movies->intersection(q.movies) & comm->size() > 2
=> Couple->exists( c | c.members = Set{p,q} & c.commonMovies = comm )

Logically this is simply a quantified assertion “for all distinct p, q in Person, if p and q have at least 3 common movies, there must exist a Couple c with members p and q, and c records the common set of movies”. But the constraint is also a prescription for a design — and the UML-RSDS tools automatically translate it to a design activity as a double for-loop:


 for (p : Person)
  do 
    for (q : Person)
    do
      if p /= q
      then 
        (Set(Movie) comm := p.movies->intersection(q.movies);
         if comm->size() > 2
         then 
           (Couple c := new Couple();
            c.members := Set{p,q};
            c.commonMovies := comm)
        )

In turn, this design can be automatically mapped to Java, C# or C++.

The principle of UML-RSDS is to specify systems in the most declarative, concise and platform-independent manner possible, and then to automate, as far as possible, synthesis of designs and executable code from the specifications.

Agility is supported, since the specification is a unified OCL + class diagram + use case model, reducing the effort of specification reworking for an incremental change. The code synthesis algorithm is optimised for efficiency, with code generally being comparable in efficiency to hand-optimised code.

Although UML-RSDS is closely related to fUML/Alf, and supports a core of corresponding UML/OCL constructs, there are significant differences: fUML is focussed on the use of actions and activities to define the detailed behaviour of operations and objects. As such, an fUML model is at a detailed design level of abstraction, rather than at a specification level. Indeed, a key omission from fUML is the concept of a constraint (invariant, precondition or postcondition). Alf provides a textual syntax for actions and activities as an alternative to graphical activity models. It is similar to imperative model transformation language notations such as Kermeta and QVT-O. In our experience, specification using constructs at a design level of abstraction leads to complex and difficult to understand definitions. Formal verification at this level has also required considerable resource commitment, and the use of complex (program) verification techniques.

Because fUML + Alf is at a lower level of abstraction, code generation becomes akin to a programming language migration task. Indeed, the behavioural semantics for fUML is expressed using Java code syntax in the fUML standard.

To summarise, a system definition is expressed by a class diagram with activities/Alf code in fUML/Alf, whilst in UML-RSDS it is expressed by a class diagram, with use cases and OCL constraints. The abstraction level in fUML/Alf is design-oriented, whilst in UML-RSDS it is specification-oriented. fUML/Alf has an execution semantics, whilst UML-RSDS has a mathematical set-theoretic and classical logic semantics.

There are also many similarities between UML-RSDS and fUML/Alf: both use OCL, although UML-RSDS adopts standard OCL 2.4 syntax and operators in most cases; both restrict the collections corresponding to association ends to be either sets or sequences; the UML-RSDS expression language is essentially a subset of Alf expressions (explicit tuples and maps are not present in UML-RSDS), and the UML-RSDS activity language is a subset of Alf statements. Many of the restrictions of fUML also apply to UML-RSDS (no instance specifications, classifier or property redefinitions, no exceptions, no property subsetting). The similarities are in fact quite striking, given that the two approaches were developed entirely independently.

The latest version (1.6) of UML-RSDS is available from www.dcs.kcl.ac.uk/staff/kcl/uml2web
A book on UML-RSDS has recently been published:

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone
Comments
  1. Lee Riemenschneider
    • Jordi Cabot
  2. Lee Riemenschneider
  3. Kevin Lano
  4. Lee Riemenschneider

Reply

Your email address will not be published. Required fields are marked *