Generate! Generate! Generate!

By Dieter E. Jenz, July 2000

It is quite surprising how little progress has been made in achieving productivity gains over the past years, despite the proliferation of CASE tools. Yet, at this time they cover only a small fragment of the software process. The software factory has still to become a reality.

Software design and development is one of the few areas where we see a strange discrepancy between theory and practice. For example, on the one hand, we all accept that quality assurance is an integral part of the software development process, and on the other hand we are quick to skip quality assurance acitvities (testing) when the project is under budget and/or time constraints. We all know of many more examples and so I won't spend more space on this.

What has driven me, as a consultant, to invest more energy into exploring ways to better automate software production is a recent observation in a large software development project. I thought, well there definitely must be ways of improvement. State-of-the-art tools were used extensively, however, but the whole thing somehow appeared cumbersome and clumsy to some extent. So, here we start out with a few thoughts about what we really need in a large software project. I will take a managerial viewpoint, which is sometimes very different from a designer's or a developer's viewpoint.

The software process

With new software development projects we use an iterative and incremental approach. There are process models like the Rational Unified Process (RUP) that describe processes and activities with their relationships and dependencies. It is worth noting that the planning unit is the iteration, not the increment. The simple reason for this is the fact that there might be no progress in terms of additional functionality in an iteration (a "zero increment").

An iteration always concludes with a specified result (a release). In an iteration we attempt to distribute the work among teams where each team has his task assignments and targets. Doing that we achieve a high degree of parallelism. For example, each team would work on a few use cases at the same time. Of course, the teams collaborate when necessary.

Today, we make extensive use of tools. At least, state-of-the-art CASE tools are seen in almost every software project. Of course, we would expect all the tools we use to support our project approach. Sadly, this is not the case. In view of all the deficiencies we recognize, we need to pause for a moment and take a holistic look at software development to determine what we really need.

We start out with business engineering or with business reengineering, if business processes have already been modeled at some earlier time. We identify business activities and group them together to use cases which are a focal point of modern software engineering. Business processes and use cases reflect customer requirements and consist of

a textual description which describes functional requirements (including pre-condition, post-condition etc.),
the user interface with all the dialog windows that are required to perform a dialog between actor and system (in fact, there are many different dialog scenarios),
a dialog map which makes the navigation paths between windows visible (see example below),
test cases for system test (there are many test scenarios for a use case),
a description of non-functional requirements (optional, only needed if specific non-functional requirements apply to the use case).

Now, I would like to describe briefly, what kind of tools would be used today:

Textual use case description: Normally, Microsoft Word or some other word processor is used to contain the textual use case description. Some CASE tools can manage links to text data files and some tools, I believe, store textual descriptions in their own repository.
Dialog windows: Typically, an IDE (eg. VisualAge, JBuilder) is used for prototyping. No one, I believe, would draw window layouts on paper. Some CASE tools have some sort of a layout editor which, however, typically is not very sophisticated and in most cases does not meet the requirements of a serious modeler.
Dialog map: There is no tool to draw dialog maps. Some CASE tools, however, now provide UML activity diagrams. This diagram type can be quite useful but needs extension towards state diagrams to cover the necessary semantics.
Test cases: At present, there are no tools to support capturing test cases for system test. Programming has not started at this point of time and so GUI capture and replay tools (eg. Mercury WinRunner) cannot be used. Thus, the only way to create test cases is to use a word processor such as Microsoft Word.
Description of non functional requirements: A word processor is the appropriate tool to capture that kind of requirements.

With iterative and incremental development, many modeling activities are performed again and again during the course of development. This implies that some or all of the work results described above get changed relatively often. For example, during a review with the customer, several changes are proposed which need to be reflected in each affected document. Almost certainly, errors are introduced by just failing to perform all of the required updates. Consistency and integrity could be lost without being detected and uncovered. In consequence, modelers might unknowingly work with an inconsistent state of requirements. There is no need to mention that this spells serious trouble at this early stage for the remainder of the software process. If there are inconsistent requirements, how do you expect to deliver correct results?

How do CASE tools help us detecting these kinds of inconsistencies? Well, they really don't. They help us to do modeling and drawing UML diagrams but they are not very good at expressing requirements as a whole. We definitely need more than that.

Are requirements management tools (RM Tools) of any great help? They are neither. They expect us to write textual requirements and in fact duplicate to a large extent what we have already modeled with use cases. Of course, RM Tools can be used to maintain general requirements that apply to all use cases, such as non-functional requirements (performance requirements, restart and recoverability requirements etc.). But they don't cover all of the ground.

To better meet the needs of parallel modeling we would be better off with a tool set that gave us the means to create and maintain requirements packages. There would be a one-to-one relationship between a use case and a requirements package. In fact, a requirements package would logically envelope a use case. Today's RM tools don't support this approach very well nor do CASE tools. So, what what would our optimal tools environment look like, then? Let's develop a scenario.

A tool scenario

First of all, we need a business process engineering tool (BPE tool). It gives us the means to model business processes. We can model activities and relate them to to other activities. We can assign roles and business entity types (eg. order, invoice) to activities. At this point of time, the entity types are not necessarily identical with classes. They are just class candidates.

We use a CASE tool to model use cases. A use case consists of one of more adjoining activities of a business process. Even, in some cases a use case may span a whole business process. Why would we not use the BPE tool to model use cases? We could do just that, functionality provided. However, we want the CASE tool to be the single point of reference for use cases. It will need to maintain links to the activities of the business process.

In any way, the BPE and CASE tools must be able to collaborate. If we change an activity in the BPE tool we need this to be signaled to the CASE tool, which in turn would mark all affected use cases as in doubt. After an "in doubt"-situation is propagated a use case modeler must make the necessary changes to reestablish synchronicity between business process and use cases.

We do not allow a use case modeler to create use cases that are not part of a business process. Almost certainly, however, during the course of use case modeling the need will arise to make changes to one or more business processes. It will show that activities are too fine grained or are too coarse grained and need further refinement. If changes are necessary, the business process needs to be worked on and subsequently subjected to a review with the customer.

While we are in the process of modeling use cases, we also need to model the dialog user interface, if the use case has one. Often, the user interface is made up of more than one dialog window. So, we lay out the dialog windows on the basis of the GUI style guide which we already have. What kind of tool would we use for that? We can make use of an IDE with an integrated GUI builder like VisualAge or JBuilder. However, these tools are quite sophisticated and would require a person with sufficient skills. It would be far better, if a modeler were able to do the dialog window layouts. Some CASE tools provide a GUI editor, though, which allows us to do just that. However, in most cases such a GUI editor is not very feature-rich and thus is of very limited value.

To put the bar higher, we not only want to make static layouts but also want to show dynamic behaviour to customer in review meetings. How can we do that? Some CASE tools feature rapid prototyping facilities that indeed make it possible to show dynamic behaviour. They can do this as they allow the GUI designer to establish links between dialog buttons and target windows. If a button is pressed, the resprective target window will show up and control will be transfered. Although this can be considered progress, it still must be characterized as a half-hearted approach. It is far better than nothing but not really what is required.

So, what is our goal? We want to develop a complete user interface for the use case, based on the GUI style guide as early as possible. The layout of each window of the user interface needs to be designed and we also want to describe dynamic behaviour. If that were achieved, we would be able to show customers at review meetings very early in the project what they would get. Customers would be able to detect logical errors earlier which saves time and money.

How can we describe structure and behaviour? The simple answer is: we need a language. A priori, an XML-based language is very well suited for describing window layout and behaviour. Based on a document type definition (DTD) or a schema we can describe window structure and window behaviour. By using a specific IDE (the ones like VisualAge or JBuilder are not suitable) we could layout each window on the screen. When we are done, a generation step would produce XML-compliant language constructs. An example for such an approach is a product of Universal Interface Technologies, Inc. They developed an XML based language which they call "User Interface Modeling Language" (UIML). A modeler would use an IDE which currently is still in development, create a user interface and then generate a UIML document. From the UIML document a renderer produces Java Code. It remains to be seen what they really deliver, but things look very promising at this time.

An XML-based language has many advantages. For example, one of the primary advantages is that we can easily interpret elements, attributes and their values. Thus, it is not very difficult to write a program that interprets a UIML document in order to produce a report with all the fields, their relations and their attributes (e.g. mandatory input/optional input, numeric/alphabetic/alphanumeric, number of input characters or digits etc.).

At this relatively early stage - development of use cases is still in progress - we can demonstrate the user interface to the customer. Functionality is still limited, though, since business logic is not available yet. Anyway, customers will be happy being able to get a near-reality impression of the user interface. A review meeting reveals if any changes are necessary. If so, changes can be applied quite easily by using the IDE. It is worth noting that we do not need to cope with one of the sophisticated IDEs yet.

Next, we need to develop a dialog map. A dialog map shows the navigation paths between windows (also, see Karl Wieger’s excellent book, titled “Software Requirements”). To develop a dialog map, again, an XML based language would be quite suitable to express relations and dependencies. Of course, we also need an editor that helps us to represent windows and draw relationships between windows. The editor would optimally be part of the IDE which we use to do window layouts. With a "generate" function we could produce a ?ML representation where ?ML could be an extended UIML.

Fig. 1: Extract from a dialog map

Alternatively, we could develop the dialog map using a UML activity diagram. However, we realize very quickly that we cannot express all the semantics we require, although the figure above shows many similarities with an UML activity diagram. The focal point, however, is not the activity but the dialog window.

We deliberately left off the standard functionality of a dialog window, such as the user help subsystem, and exception conditions like “database not available”. The dialog map would become too cluttered and, for reviews with the customer, this level of detail will prove sufficient.

So far, we can develop use cases and use case diagrams and the user interfaces. Now, we can think about testing. As is long accepted, at least in theory, test cases for system test need to be developed very early. However, with CASE tools you only find very limited support, if any, for system testing.

We could generate test cases (i.e. test scenarios) from the dialog map. Every path in the dialog map would need to be identified and results in at least one test case for system test. At least a skeleton could be generated for every test scenario (the test values are not necessarily known yet at this time and need to be substituted by generic "values" (e.g. "invalid customer number" or "valid customer number")). Path derivation occurs pretty mechanical and can be automated quite easily. A test scenario skeleton would consist of the status at the beginning of test case execution, the input values required to start test case execution, the expected flow of events and the status at the end of test case execution (expected results). Every test case could later be edited and completed.

Our dialog map shows only the dialog windows that are of direct relevance to the user. Based on the GUI style guide we can automatically generate test case scenarios for standard functionality and exception conditions. The total number of test case scenarios is the sum of the explicitely visible navigation paths in the dialog map, the standard functions and the relevant exception conditions.

Although complete generation of test scenarios is not possible, a significant productivity gain could still be expected (in the example dialog map above, around 20 test scenarios (I have not counted) would be needed for system test). From the completed test scenarios, test scripts for a GUI test tool like Mercury Interactive's WinRunner could potentially be generated. Generation of test scenario skeletons is a tremendous step ahead if you consider how much time it takes to develop a test scenario manually. If we assume manual development of a test scenario would take us 30 mins. and generation saved you 50% of the time required, that would quite easily amount to hundreds of work hours, let alone that generated test scenario skeletons are less error-prone.

You may have an objection when it comes to generation of test scenarios. Can we really generate test scenario skeletons from the user interface? Yes, we can. Provided that a review of the dialog windows and the dialog map has taken place and the customer has agreed to what was shown to him, then he has approved the specification. The customer is responsible for the correctness of the requirements in the context of his business and the modeler is responsible for the formal consistency of the requirements. If the customer approves the requirements then the modeler cannot do any better and generated test scenario skeletons are automatically in sync with the requirements (provided that generation works correctly, of course). If the dynamic behaviour of the user interface can be shown to the customer he is able to detect errors almost immediately and this would also contribute to establish confidence that requirements are met.

Test scenarios can be completed at some later time, just before system test is due. Whenever the dialog map changes, test scenario skeletons can be regenerated. Since changes to the user interface and/or the dialog map occur relatively often during the early stages of use case modeling, rework can be minimized by postponing test scenario specification to the latest point in time possible.

Summary

With an iterative and incremental approach with teams working in parallel we must find viable ways to enhance productivity and, at the same time, minimize the potential for errors that remain undetected for too long. We need to be able to work with requirements packages as early in the process as possible.

As we all know, requirements change very often. In consequence, we must be able to apply changes to requirements packages and regenerate depending products (like test scenario skeletons). XML-based languages help us enormously to achieve this goal.

So, what can we generate, then? From a dialog window description, we can generate Java-code and we can also generate various reports that are of help in offline reviews. Also, we can generate test scenario skeletons from dialog maps. Productivity gains will be enormous while, at the same time, we improve quality and shorten development time. We can regenerate quite easily and thus reduce the potential of human error. The downside is: we don’t have the whole suite of required tools yet. However, I am confident that gaps will be closed pretty soon.

There are no experiences from the past, which prove this approach. We have to explore new paths. Watch out for developments in the XML space. New tools will appear on the market. Evaluate their potential and make use of them. Significant productivity gains are a safe bet.

Products or trade names are trademarks or registered trademarks of their respective owners