Shmuel S. Tyszberowicz

Behavioral consistency validation of UML diagrams

UML provides several kinds of diagrams to model the behavior and structure of a system under development. A consistency problem may arise due to the fact that some aspects of the model may be described by more than one diagram. Hence, it is important that the consistency of the system description should be checked before implementing it. This paper describes an algorithmic approach to a consistency check between UML sequence and state diagrams. The algorithm we provide also handles complex state diagrams, e.g. diagrams that include forks, joins, and concurrent composite states. We describe the algorithm in detail, and elaborate on the design decisions made while developing the algorithm. We have implemented BVUML, a tool that assists in automating the validation process.

OBSERV—a prototyping language and environment

The OBSERV methodology for software development is based on rapid construction of an executable specification, or prototype, of a systems, which may be examined and modified repeatedly to achieve the desired functionality. The objectives of OBSERV also include facilitating a smooth transition to a target system, and providing means for reusing specification, design, and code of systems and subsystems. We are particularly interested in handling embedded systems, which are likely to have concurrency and have some real-time requirements. The OBSERV prototyping language combines several paradigms to express the behavior of a system. The object-oriented approach provides the basic mechanism for building a system from a collection of objects, with well-defined interfaces between them. We use finite-state machines to model the behavior of individual objects. At a lower level, activities that occur within objects, either upon entry to a state or in transition between thus allowing a nonprocedural description. The environment provided to a prototype builder is as important as the language. We have made an attempt to provide flexible tools for executing or simulating the prototype being built, as well as for browsing and static checking. The first implementation of the tools was window based but not graphic. A graphic front end, name CRUISE, was developed afterwards. A simulation sequence focuses on a single object, which can be as complex as necessary, possibly the entire system, and expects all the interactions between it and the outside world to be achieved by communication between the simulator and the user. The simulator allows the user to easily switch back and forth from one object to another, simulating each object in isolation. To enable testing the behavior of a prototype in a realistic environment, it is possible to construct objects that imitate the environment objects. We also allow simulation of systems with missing pieces, by calling upon the user to simulate any such missing piece by himself.

Jose: Aspects for Design by Contract80-89

Design by contract is a practical methodology for evolving code together with its specification. The contract has important methodological implications on the design of the program. In addition, tools that instrument the code to check for contract violations help the development process by catching errors close to their sources. This is complicated by several factors, such as the need to collect preconditions from supertypes. There are two issues involved in the implementation of such a tool: the correct enforcement of the theoretical principles, and the instrumentation of the code. Most previous tools tackle both issues, but have subtle failures in one or the other. This paper describes Jose, a tool for design by contract in Java, which uses AspectJ, an aspect-oriented extension of Java, to instrument the program. This allows us to leverage the expertise of the AspectJ developers in instrumenting Java programs, and concentrate on the correct implementation of the design by-contract principles. This approach has the added benefit that it can be generalized to other object-oriented languages that have aspect-oriented extensions. We describe the design decisions made in the implementation of Jose, and the features of AspectJ that helped or hindered this implementation

The EasyCRC Tool

CRC cards are an informal approach to object oriented modeling, used to represent the responsibilities of classes and the interaction between the classes. They are created through white-box scenarios that model the behavior of the system. Sequence diagrams are the most popular UML artifact for scenarios modeling. Though closely related, the CRC cards methodology is not supported by most UML modeling tools, and tools that support CRC cards do not support UML diagrams. This paper presents EasyCRC, a tool that combines sequence diagrams with CRC cards, originally written to teach the object-oriented paradigm.

GenUTest: a unit test and mock aspect generation tool

Unit testing plays a major role in the software development process. What started as an ad hoc approach is becoming a common practice among developers. It enables the immediate detection of bugs introduced into a unit whenever code changes occur. Hence, unit tests provide a safety net of regression tests and validation tests which encourage developers to refactor existing code with greater confidence. One of the major corner stones of the agile development approach is unit testing. Agile methods require all software classes to have unit tests that can be executed by an automated unit-testing framework. However, not all software systems have unit tests. When changes to such software are needed, writing unit tests from scratch, which is hard and tedious, might not be cost effective. In this paper we propose a technique which automatically generates unit tests for software that does not have such tests. We have implemented GenUTest, a prototype tool which captures and logs interobject interactions occurring during the execution of Java programs, using the aspect-oriented language AspectJ. These interactions are used to generate JUnit tests. They also serve in generating mock aspects—mock object-like entities, which enable testing units in isolation. The generated JUnit tests and mock aspects are independent of the tool, and can be used by developers to perform unit tests on the software. Comprehensiveness of the unit tests depends on the software execution. We applied GenUTest to several open source projects such as NanoXML and JODE. We present the results, explain the limitations of the tool, and point out direction to future work to improve the code coverage provided by GenUTest and its scalability.

Locating regression bugs

A regression bug is a bug which causes a feature that worked correctly to stop working after a certain event (system upgrade, system patching, daylight saving time switch, etc.). Very often an encompassed bug fix included in a patch causes the regression bug. Regression bugs are an annoying and painful phenomena in the software development process, requiring a great deal of effort to find. Many tools have been developed in order to find the existence of such bugs. However, a great deal of manual work is still needed to find the exact source-code location that caused a regression bug. In this paper we present the CodePsychologist, a tool which assists the programmer to locate source code segments that caused a given regression bug. The CodePsychologist goes beyond current tools, that identify all the lines of code that changed since the feature in question worked properly (with the help of a Source Control Tool). The CodePsychologist uses various heuristics to select the lines most likely to be the cause of the error, from these often large number of lines of code. This reduces the fixing time of regression bugs. It allows a quick response to field errors that need an immediate correction.

Refactoring with contracts

Design by contract is a practical methodology for developing code together with its specification. The contract consists of class invariants and method pre-and postconditions. As the code is refactored, specifications of internal units change with the code. There are mutual influences between the code and the contract. The assertions that constitute the contract are Java expressions; refactorings such as rename method must change these assertions as well as the code. The contract has methodological implications, which serve as preconditions on some refactorings; these must be checked before performing those refactorings. In addition, some contract modifications follow from certain refactorings, and can be done automatically. Development environments that support design by contract must take these influences into account. We report on the implementation in Eclipse of several refactorings that involve both code and contract. These show how contracts are modified in response to code changes, how contracts prevent certain changes, and how new contracts are computed for newly-generated methods and classes

Specifying a Linked Data Structure in JML for Formal Verification and Runtime Checking

We show how to write a concise and elegant specification of a linearly linked data structure that is applicable for both verification and runtime checking. A specification of linked lists is given as an example. The concept of a list is captured by an observer method which is a functional version of a reachability predicate. The specification is written in the Java Modeling Language (JML) and does not require extensions of that language. This paper addresses a mixed audience of users and developers in the fields of formal verification, runtime checking, and specification language design. We provide an in-depth description of the proposed specification and analyze its implications both for verification and for runtime checking. Based on this analysis we have developed verification techniques that fully automate the verification process, using the KeY tool, and that are also described here.

Derived Requirements Generation: The DRAS Methodology

In the early stages of system development, many requirements interdependencies exist. Interacting requirements may conflict with one another and they may impact (change, enhance, or override) other requirements as well. Those interdependencies should be identified as early as possible in the development lifecycle. Conflicts should be resolved, so as to avoid the cost and schedule overhead that comes when detecting them late in the development process. Properly identifying the interactions, during the requirements elicitation and analysis, results in new and modified Derived Requirements (DRs). These DRs resolve interactions and undesirable conflicts. An important kind of requirements which interact with other requirements is crosscutting Functional Requirements (FRs). The DRAS (Derived Requirements generation based on Actions and States) methodology presented in this paper helps both to identify FRs that crosscut other FRs and to generate the derived or modified requirements. To identify crosscutting requirements, the methodology matches the actions used by the requirement and the system modes and states related to these requirements. When the same action is used by two requirements it might indicates that one of the requirements may crosscut the other. In addition to actions directly used, DRAS takes into account also actions implied by them. For a specific action Act (referred to by a requirement), DRAS uses the following implied-actions: (a) Actions that are activated as a consequence or result of using Act, or (b) Actions that Act is the consequence of their use.

Improving Design Decomposition

Decomposing a system into subsystems is essential to the design of large software systems. Traditionally, it is performed intuitively without rigorously analyzing the system model. This makes it difficult to check the decomposition correctness, and risks creating subsystems that are either too tightly coupled or not cohesive enough. An aggravating factor is that traditionally classes are the atomic design units. In many cases, however, the same classes play a role in more than one subsystem, and partitioning them unbroken among the subsystems may increase coupling and reduce cohesion. We present an analytical approach that enables reasoning about early exploration of decomposition alternatives. In addition, we describe a visual notation for diagramming the composition of subsystems, and an automatic technique for suggesting good decompositions. A key to our approach is that individual relations, not classes, are the atomic design units. We illustrate the approach with examples and demonstrate its effectiveness on a commercial system.