A history note:

The limitations of representations such as lines of code on paper (inherently static) were pointed out by the late Edsgar Dijkstra back in the earliest days of programs design. For similar reasons -viewing programs as dynamic processes- Michael A. Jackson and Microfocus offered a dynamic test feature (Check & Animate) already in the 1980-ies, with a round-trip traceability between diagrams and code. It ran as an add-on in the testing environment of Microfocus Workbench on PCs under DOS. Despite of this rather limited machinery, it animated both code and the corresponding boxes in program-structure diagrams - on a split screen, because window handling emerged much later in PCs (so in those days, the tester used function keys instead of clicks). Most of this Animator Link was made by my colleague at M. A. Jackson Scandinavia, Leif Carlsson. Today, this practical European pioneer idea is undergoing a revival thanks to UML2 tools. In the next 5 to 10 years, I expect diagram-and-code animation to become just as common as simulation or VR has become in complex manufacturing. Of course we’ll be using several windows or splits because a good UML model results in several views (types of diagram), plus the generated code.

With its intro-paragraph shortened (thus making it almost polite :-) this contribution was published by IDG/Computerworld (US), April 14, 2003 as a letter to the editor (Subject: Give Me a Test Hook or Else).

What Code Generators Should Do

- hooks on & off for testing

Linda Hayes (CTO, WorkSoft) has made a good point. Switching "hooks" on and off repeatedly, on demand, is IMO a standard task to be performed by code generators. Both software and brainware might go crazy some time. Typically however, a software error is at least a more or less consistent sort of mess whereas a human one is rather random... That's why the task of comment-marking (and un-marking) particular labels or lines of code fits into codegen. In addition, once you have your automation machinery in place, some of the political issues discussed in her article can be defused: "you're right in a sense, tested and deployed code are not exactly identical; nevertheless, full consistency of all the business logic is ensured by a software tool and I think we can be happy with that". 

With model execution & blueprint testability in UML 2, UML-blueprints and test-tools are increasingly intertwined.

There are also several graphical object-animator features around (Select, Telelogic, and several clear-cut-RT tools). Telelogic's way of using a UML2 sequence diagram as a test menu is a handy piece of pioneering work, likely to be followed by the UML-tool and the test-tool communities.

The problem Linda is addressing in tests (reused "non-standard" components) looks similar in code-generator design, a business that is undergoing a leap, triggered by new high-level action-spec languages used with the UML. Even standard C++ code with STL, which has been a straightforward case of codegen for 5-7 years, might look a bit funny when automatically reverse-engineered into UML; in come cases, business objects tend to get intermixed with things like stacks, lists, containers etc - that is, components from a tech-level library that is almost a part, or extension, of the programming language itself. Developers often need a hide-all facility, sensitive to these "low STL-level" components . Obviously, using a standardized set of marks (possibly, XML-tags) on the lines of code makes two-way tracing and detection easier. As the proportion of generated code leaps in UML 2.0, so does complexity of the combination codegen-OTScomponents-testing. Component reuse is a best practice. Nevertheless, that's exactly why reusers need not only component certification but also component testability - at a click.  

Milan Kratochvil, IT-consultant since 77

(involved already in the late 80ies in integrating diagram-based PC-codegen with an animator and a testbench by Microfocus) 

Back, Kiseldalens Top Page