Download (direct link):
Ensuring the testability of the components is a normal part of the implementation cycle workflow. Both unit tests and component tests are created and maintained by the developer as part of each convergent component. Similar to other artifacts, significant parts of these
Chapter 6: The Development Process
test artifacts can be generated from the UML model and completed in the Java IDE. The test workflow described later provides more information on test artifacts.
At this point, the developer begins a rapid design and implementation cycle. Each cycle consists of an incremental increase in system capability and its commensurate test features. In each cycle, the developer moves back to the UML model, changes or extends the model, and regenerates the respective infrastructure. The developer then proceeds to the Java IDE to add more custom code to the component and its test artifacts. The Java IDE is used to automatically compile, build, deploy, and run the components, including the accessors. The developer then runs the accessors and the test artifacts in the Java IDE to check the business and technical features of the system and to trace and debug any problems introduced during custom coding.
In the later iteration or the construction phase, editing may be unnecessary. The developer or testers may want to regenerate, build, and test the system without accessing the UML tool or the Java IDE. This is especially true for automatic tests of assemblies and components, where entire models are checked out directly from the UCM pool and then generated, built, deployed, and tested without human intervention. Such automatic tests will be carried out on a regular basis, nightly, for example, once the project has matured well into the construction phase. To support the large-scale automatic testing of components, infrastructure, and tools, the technology projection cartridges also generate command-line scripts to carry out the cycle. Based on these scripts, command-line processing can be started by calling the generator (C-GEN module) from the command line to access the UML model (via the C-REF module) and generate the infrastructure. The scripts also provide command-line commands for the rest of the compile, build, deploy, and test cycles. The level of support for these phases depends, of course, on the particular technology projection cartridge.
Developers may need to modify or extend the capabilities of technology projection cartridges. This is done using the generator IDE module of the architectural IDE. A simple modification that is frequently made to a cartridge is, for example, to add the corporate logo and other graphics to the default HTML representers. As explained in Chapter 4, the HTML representer is the HTML front end generated by a cartridge. To modify the graphic design produced every time the generator is run, a developer or development tool expert may edit, test, and debug the new graphic design using the generator IDE. Once tested, this cartridge change may become part of the default cartridge to be used by all other projects. However, such changes to cartridges should only be made with consent of the chief architect. More details concerning the content of cartridges and their relationship to the architectural IDE are provided in the next two chapters.
The desirable side effect of this cycle is that the design is always in sync with the implementation, the integrity of the design is immediately verified at the UML level, and the system design is implicitly documented in UML.
Chapter 6: The Development Process
A mature model-driven approach significantly reduces the amount of code that must be tested. However, at least three good reasons remain as to why effective test coverage is needed. First, even the best UML models and their technology projections are not formal proof that the generated system will work as expected. Mature modeling and well-tested technology projection cartridges do reduce the source of error significantly, but one is never 100-percent sure until the system is tested. This uncertainty is inherent in the complexity of application-server and networked-system environments. Clearly, these servers and environments are themselves not without error. Second, any models and code entered by humans during the implementation workflow are subject to human oversight. Testing is the only effective way to check their correctness. Third, and most significant, we need to verify that the business representation, the business dimension, is really doing what we said it would. No matter how good we are at reducing errors, there will always be residual uncertainties—in the foreseeable future anyway—that can be reduced further only through adequate testing. The architectural style deals with this reality by encompassing a test workflow and its respective organizational and tool support.
Here again, the model-driven approach affords the most effective test coverage. Figure 6.9 illustrates this approach as supported by the architectural IDE. To the left are the UML models that conform to a well-defined modeling style. Thus, significant aspects of the test infrastructure can be derived and generated automatically from the models. Similar to the generation of default accessor models mentioned earlier, testing models also can be derived from the business component models—models used to generate other models. Based on the default test models, a developer can add specialized testing features at the UML level. The right of the figure shows how test components, instrumentation, and the automation infrastructure are generated, as always, by way of the technology projection cartridge. The generated infrastructure is now model-specific, enabling the test of both business logic and technical infrastructure. The level of automatically generated support for various types of tests is evolving rapidly and is, as always, dependent on the current state of the modeling style and particular technology projection.