Sang-Uk Jeon

An automated refactoring approach to design pattern-based program transformations in Java programs

Software often needs to be modified to accommodate requirements changes during the software lifecycle. To deal with several accidental requirements changes related to software maintenance, a systematic and safe approach to modifying software is needed. Design patterns provide a high degree of design flexibility for such accidental requirements changes. In this paper, we propose an automated approach to refactoring based on design patterns in Java programs. In our approach, for a particular design pattern, we define an inference rule to automatically identify a set of candidate spots and a refactoring strategy to transform a candidate spot into the desired design pattern structure. A candidate spot may be a class or a set of classes to which design patterns can be applied. We believe that our approach would be helpful to maintainers in the sense that much manual analysis of source code can be reduced, and the method of automated program transformation preserves behavior of the original program by means of the refactoring technique.

Behavioral Dependency Measurement for Change-Proneness Prediction in UML 2.0 Design Models

During the development and maintenance of object-oriented (OO) software, the information on the classes which are more prone to be changed is very useful. Developers and maintainers can make a more flexible software by modifying the part of classes which are sensitive to changes. Traditionally, most change-proneness prediction has been studied based on source codes. However, change-proneness prediction in the early phase of software development can provide an easier way for developing a stable software by modifying the current design or choosing alternative designs before implementation. To address this need, we present a systematic method for calculating the behavioral dependency measure (BDM) which helps to predict change-proneness in UML 2.0 models. The proposed measure has been evaluated on a multi-version medium size open-source project namely JFreeChart. The obtained results show that the BDM is an useful indicator and can be complementary to existing OO metrics for change-proneness prediction.

Measuring behavioral dependency for improving change-proneness prediction in UML-based design models

Several studies have explored the relationship between the metrics of the object-oriented software and the change-proneness of the classes. This knowledge can be used to help decision-making among design alternatives or assess software quality such as maintainability. Despite the increasing use of complex inheritance relationships and polymorphism in object-oriented software, there has been less emphasis on developing metrics that capture the aspect of dynamic behavior. Considering dynamic behavior metrics in conjunction with existing metrics may go a long way toward obtaining more accurate predictions of change-proneness. To address this need, we provide the behavioral dependency measure using structural and behavioral information taken from UML 2.0 design models. Model-based change-proneness prediction helps to make high-quality software by exploiting design models from the earlier phase of the software development process. The behavioral dependency measure has been evaluated on a multi-version medium size open-source project called JFlex. The results obtained show that the proposed measure is a useful indicator and can be complementary to existing object-oriented metrics for improving the accuracy of change-proneness prediction when the system contains high degree of inheritance relationships and polymorphism.

An approach to identifying causes of implied scenarios using unenforceable orders

Context: The implied scenarios are unexpected behaviors in the scenario specifications. Detecting and handling them is essential for the correctness of the scenario specifications. To handle such implied scenarios, identifying the causes of implied scenarios is also essential. Most recent researches focus on detecting those implied scenarios, themselves or limited causes of implied scenarios. Objective: The purpose of this research is to provide an approach to detecting the causes of implied scenarios. Method: The scenario specification is a set of events and a set of relative orders between the events, and enforces them for its implementation. Among the orders, a set of orders that cannot be inherently enforced is the unenforceable orders. Obviously, existence of unenforceable orders leads the implied scenarios. To obtain the unenforceable orders, we first provide a method to represent each of the specification and its implementation as a set of orders between events, called the causal order graph. Then, the differences between them are the unenforceable orders. Results: Because the unenforceable orders consist of events and their order relation that are specified in the scenario specification, they can point out which part of the scenario specification should be considered to handle the implied scenarios. In addition, our approach supports the synchronous, asynchronous, and FIFO communication styles without the state explosion or heavy computational overhead. To validate our approach, we provide two case studies. Conclusions: This approach helps a designer to effectively correct the scenario specification by identifying where to be fixed, especially in large cases and under the various communication styles.

Interaction-based behavior modeling of embedded software using UML 2.0

Many prior approaches in UML-based embedded software design incorporate state-based behavior modeling. However, interaction-based behavior modeling provides more intuitive view of a system. In this paper, we propose an approach to interaction-based behavior modeling of embedded software using UML 2.0. We use the interaction overview diagrams and the sequence diagrams to model the behavior. We present the method of constructing interaction-based behavior model with an example. We also briefly describe the idea of generating executable code from it

Developing platform specific model for MPSoC architecture from UML-based embedded software models

In this paper, we describe a technique to design UML-based software models for MPSoC architecture, which focuses on the development of the platform specific model of embedded software. To develop the platform specific model, we define a process for the design of UML-based software model and suggest an algorithm with precise actions to map the model to MPSoC architecture. In order to support our design process, we implemented our approach in an integrated tool. Using the tool, we applied our design technique to a target system. We believe that our technique provides several benefits such as improving parallelism of tasks and fast-and-valid mapping of software models to hardware architecture.

A Graph Based Approach to Detecting Causes of Implied Scenarios under the Asynchronous and Synchronous Communication Styles

The implied scenarios are unexpected behaviors in the scenario specifications. Detecting and handling them is essential for the correctness of the scenario specifications. Prior researches focus on detecting those implied scenarios through error traces, and cannot identify where to be considered to handle the implied scenarios. Moreover, most of them do not consider the asynchronous communication style although the implied scenarios may vary according to communication styles. In this paper, we provide a graph based approach to detecting causes of implied scenarios under the asynchronous and synchronous communication styles. The semantics of the scenario specification is defined as a partially ordered set which is represented as a graph. Based on the graph, our approach constructs another graph which represents behaviors of a minimal implementation satisfying the scenario specification. Differentiating between the two graphs identify which part of the scenario specification causes the implied scenarios under the asynchronous communication style. In addition, our approach can be also applied under the synchronous communication styles by adding additional relationships to the two graph. To validate our approach, we provide two case studies.

Using Operational Architecture to Model Embedded Software

Almost methods in embedded software modeling take software architecture as one of the crucial parts of the design process. Since a principal role of embedded software is the interaction with its environments, architectures that describe the dynamic aspects are also needed. Although such architectural view is significantly important in embedded software development, the existing approaches do not practically guide the architectural design based on the dynamic aspects. In this paper, we propose an operational architecture to represent the dynamic aspects of an embedded software. Also we explain how to use our operational architecture in the process of embedded software modeling. Our operational architecture effectively reflects interaction-based dynamic behavior of the system, and gives traceability between requirements and design model.