Automatic Debugging Support for UML Designs

Automatic Debugging Supp ort for UML Designs Johann Schumann RIACS / NASA Ames, Mo ett Field, CA 94035 USA, [email protected] Summary. Design of large software systems requires rigorous application of software engineering metho ds covering all phases of the software pro cess. Debugging during the early design phases is extremely imp ortant, b ecause late bug- xes are exp ensive. In this pap er, we describ e an approach which facilitates debugging of UML requirements and designs. The Uni ed Mo deling Language UML is a set of notations for ob ject-orient design of a software system. Wehave develop ed an algorithm which translates requirement sp eci cations in the form of annotated sequence diagrams into structured statecharts. This algorithm detects con icts b etween sequence diagrams and inconsistencies in the domain knowledge. After synthesizing statecharts from sequence diagrams, these statecharts usually are sub ject to manual mo di cation and re nement. By using the \backward" direction of our synthesis algorithm, we are able to map mo di cations made to the statechart backinto the requirements sequence diagrams and check for con icts there. Fed back to the user con icts detected by our algorithm are the basis for deductive-based debugging of requirements and domain theory in very early development stages. Our approach allows to generate explanations on why there is a con ict and which parts of the sp eci cations are a ected. 1 Intro duction Size and complexity of software systems has increased tremendously. There- fore, the development of high-quality software requires rigorous application of sophisticated software engineering metho ds. One such metho d which has b ecome very p opular is the Uni ed Mo deling Language. UML [12] has b een develop ed by the \three amigos" Bo o ch, Jacobson, and Rumbaugh as a common framework for designing and implementing ob ject-oriented software. UML contains many di erent notations to describ e the static and dynamic b ehavior of a system on all di erent levels and phases of the software design pro cess. Although UML provides a common notational framework for requirements and design, UML, as any other language, do es not eliminate bugs and errors. These bugs must be found and xed in order to end up with a correctly working and reliable system. It is well known, that debugging a large software system is a critical issue and can be a ma jor cost-driving factor. Changes whichhave to b e applied to the system e.g., to x a bug 2 Johann Schumann are b ecoming substantially more exp ensive, the later they are detected Fig- ure 1. When an error is detected early during the de nition phase, its cost is relatively low, b ecause it only in uences the requirements de nition. Bug xes in a pro duct already shipp ed can b e up to 60{100 times more exp ensive [8]. 60 - 100 relative cost to change 1.5 - 6 1 Definition Development after Release Fig. 1. Relative costs for changes/bug xes on di erent stages based on [8 ]. Therefore, it is mandatory to start with debugging as early in the pro ject as p ossible. In this pap er, we will discuss an approach which supp orts debugging of scenarios more precisely UML sequence diagrams with resp ect to given domain knowledge. This is done as a part of an algorithm [13] which can synthesize UML statecharts from a numb er of sequence diagrams. This synthesis step can b e seen as a transformation from requirements to system design. It do es not only facilitate fast and justi able design from requirements sequence diagrams, but also substantially helps to debug the generated designs. Because sequence diagrams usually cover only parts of the system's intended b ehavior, the generated statecharts need to be re ned and mo di- ed manually. By applying the synthesis algorithm in a \backward" way, the re ned statechart can b e checked against the requirements. Each con ict is rep orted to the user and indicates a bug. For practical applicabilityofany debugging aid, the presentation of the bug, its cause and e ect is of ma jor imp ortance. In our approach, we rely on logic-based explanation technology: all con icts corresp ond to failure in log- ical reasoning ab out sequence diagrams, statecharts, and domain knowledge. Ongoing work, as discussed in the conclusions, uses metho ds from automated deduction to p oint the user to the exact place where the con ict o ccurred and which parts of the mo dels and sp eci cation are a ected. This pap er is organized as follows: Section 2 gives an overview of ma- jor UML notations and a typ cial iterative software design pro cess. Then we will describ e how sequence diagrams are annotated for a justi ed synthesis Debugging Supp ort for UML Designs 3 of statecharts Section 4. Based on this algorithm we discuss metho ds for debugging a sequence diagram and a synthesized statechart. In Section 7 we discuss future work and conclude. Throughout this pap er, we will use one example to illustrate our approach. The example concerns the interaction b etween an espresso vending machine and a user who is trying to obtain a cup of co ee. This example based on the ATM example discussed in [13,6] is rather small, yet complex enough to illustrate the main issues. The requirements presented here are typical scenarios for user interaction with the machine e.g., inserting a coin, selecting the typ e of co ee the user wants, reaction on invalid choices, and pressing the cancel button. More details of the requirements will b e discussed when the corresp onding UML notations have b een intro duced. 2 UML The Uni ed Mo deling Language is the result of an e ort to bring together several di erent ob ject-oriented software design metho ds. UML has b een develop ed by Booch, Jacobson and Rumbaugh [12] and has gained wide-spread acceptance. A variety of to ols supp ort the development in UML; among them are Rhapso dy [10], Rational's Rose [9], or Argo/UML [1]. On the top-level, requirements are usually given in the form of use cases , describing goals for the user and system interactions. For more detail and re nement, UML contains three ma jor groups of notations: class diagrams for describing the static structure, interaction diagrams for requirements, and state diagrams and activity diagrams for de ning dynamic system b ehavior. Below, we will illustrate the notations which are imp ortant for our approach to debugging of UML designs. 2.1 Software Development with UML Although no explicit development pro cess is prescrib ed for UML, UML design usually follows the steps of Inception, Elab oration, Construction, and Transition, used in an iterative manner. In this pap er, we will not elab orate on the pro cess mo del. For details, cf., e.g., [4]. The imp ortance of supp ort for debugging of UML designs on the level of sequence diagrams requirements, and statecharts b ecomes evident, when we lo ok at a graphical representation of an iterative development pro cess Figure 2. The design starts by analyz- ing the physical pro cess at the lower left part of the gure. The result of the analysis comprises the requirements e.g., as a set of sequence diagrams, and know ledge ab out the domain henceforth called domain theory. Based on these, a model of the system is develop ed, consisting of class diagrams, statecharts and activity diagrams. This mo del must now be implemented. Mo dern software engineering to ols provide automatic co de-generation or at 4 Johann Schumann least supp ort for this step. Finally, the pro duced system must be veri ed against the physical pro cess, and its p erformance tuned. Traditionally, the way to get a working system is simulation pro cess{ requirements{mo del, and testing requirements{mo del{system. Here, errors and bugs have to b e found and removed. Within an iterative design pro cess, these steps are p erformed over and over again, depicted by the circular arcs. To keep these iterations fast and thus cost-e ective, powerful techniques for debugging requirements against domain knowledge, and mo dels against requirements are vital. Our approach supp orts this kind of debugging and it will b e discussed in the next section, following a short description of the basic concepts of class diagrams, sequence diagrams, and statecharts. Development Requirements Model specification Code Generation SimulationTesting Analysis Process System Performance tuning/ -verification Fig. 2. Iterative Design Pro cess 2.2 Class Diagram A class diagram is a notation for mo deling the static structure of a system. It describ es the classes in a system and the relationships b etween them. Figure 3 shows an example of a class diagram for our co ee-vending machine example. In an ob ject-oriented fashion, the main class here \co ee machine" is broken down into sub-classes. The aggregation relation 3 shows when one class is part of another one. The generalization relation shows when one class is an instanceof another. For further details, see e.g., [12]. 2.3 Statecharts Statecharts [5,12], are nite state machines extended with hierarchy and or- thogonality. They allow a complex system to b e expressed in a compact and Debugging Supp ort for UML Designs 5 top-level physical dialog Cancel device handling Coin Cup Coffee-type Machine checker dispenser selector Controller Fig.

Load more