What Makes Executable UML Unique
Created | Updated Mar 19, 2002
[ Back To Entry: Executable UML ]
Requirements Not Solutions
The UML notation provides a broad range of diagramming notations to emcompass several different development methods. It also aims to provide notation for all of the development lifecycle from requirements analysis, through design, to describing the packaging of the compiled work products.
Executable UML is interested in what not how, and consequently uses only those parts of the UML notation that describe required behaviour. Not design issues. Not programming issues. Not packaging issues.
How you move from requirements to design is dependent upon the development method in which you choose to place the Executable UML notation. You may choose to elaborate from your executable models using the design notation from UML, or you may choose direct translation by archetype. Whichever method you choose, the Executable UML notation provides your first (and independent) step.
Testable Requirements
Most real systems tend to arrive at the analysts door either as a very sketchy idea, or as seveal hundred pages of dense and conflicting textual requirements, or very occasionally as detailed protocol specifications. From those requiremnts the analyst attempts to produce a complete and consistent set of reuqirements from which a design may be constructed. There are many analysis methods that may be used to acheive this, structured, object oriented, or component based. The problem the analyst faces is:
How do you know if the requirements model you have drawn actually does what you expect?
You can do this by implementing and testing (but means major requirements faults are found very late in the development cycle, and you have to try and work out whether you have a requirements bug or an implementation bug which in real-time systems is no joke), by rapid prototyping of risky areas, or by manual review of use-cases against the specified model. Or you can execute your requirements model as if it were a program, and that is what Executable UML is all about.
Executable UML allows you to describe your system in terms of use-cases and sequence diagrams and then to use those sequence diagrams to execute the model and test that for each external stimulus in sequence, the model produces the expected responses.
Executable UML therefore allows you to test for correct system behaviour independent of your implementation. This should mean that the bugs you find during implementation are actually implementation bugs and not requirements/logic bugs. Also if you are implementing across multiple platforms, it means that you can test the logic of your model once rather than on every system platform.
Your Documentation Is Your Code
Depending on how you choose to move from your executable UML model to code, a process sometimes referred to as implementing an Executable UML profile, it is possible to automatically translate your UML diagrams and action language directly to executable code. The exact process depends upon whther you choose elaboration or translation by archetype, but with both techniques full code generation to target is possible.
That means of course, that your code matches its documentation, and a change to the requirements can easily and reliably be traced to the code and impact assements be done.
