Reverse Engineering Software Code in Java to Show Method Level Dependencies

With the increased dependency on the Internet and computers, the software industry continues to grow. However, just as new software is being developed, older software is still in existence and must be maintained. This tends to be a difficult task, as the developers charged with maintaining the software are not always the developers who designed it. Reverse engineering is the study of an application\u27s code and behavior, in order to better understand the system and its design. There are many existing tools that will assist the developer with this undertaking, such as Rational Rose®, jGRASP®, and Eclipse®. However, all the tools generate high level abstractions of the system in question, like the class diagram. It would be more beneficial to developers to have illustrations with more detailed information, such as the method level dependencies in the source code. In order to accomplish this task, a new framework has been developed that will allow the user to view both high level and lower level code detail. As users attempt to perform code maintenance, they will run the code through an existing tool, such as Rational Rose®, and then through the Method Level Dependency Generator component, to show the method level dependencies. These tools used together provide the software maintainer with more useful information, assisting with the software development process, including code design, implementation, and testing

Feature-based Approach to Bridge the Information Technology and Business Gap

The gap between business goals (problem domain), such as cost reduction, new business processes, increasing competitive advantage, etc., and the supporting Information Technology infrastructure (solution domain), such as the ability to implement software solutions to achieve these goals, is complex and challenging to bridge. This gap emerges for many reasons; for instance, inefficient communication, domain terminology misunderstanding or external factors, e.g. business change. As most business and software products can be described by a set of features, a promising solution would be to link both the problem and solution domains based on these features. Thus, the proposed approach aims to bridge the gap between the problem and the solution domains by using a feature-based technique in order to provide a quick and efficient means for understanding the relationships between IT solutions and business goals. The novelty of the proposed framework emanates from the three characteristics of the business-IT gap: the problem domain, the solution domain and the matching process. Besides the proposed feature-based IT-business framework, other contributions are proposed: a feature extracting method and feature matching algorithms. The proposed approach is achieved in three phases. The first phase is to decompose business needs and transform them into a feature model (presented in UML diagrams); this is represented as a top-to-middle process. The second phase is a reverse engineering process. A system program code is sliced into modules and transformed into feature-based models (again, in UML diagrams); these are represented as a bottom-to-middle process. The third phase is a model-driven engineering process. It uses model comparison techniques to match the UML feature models of the top-to-middle and bottom-to-middle phases. The presented approach in this research shows that features elicited from the business goals can be matched to features extracted from in the IT side. This proposed approach is feasible and able to provide a quick and efficient means for improving feature-based business IT matching. Two case studies are presented to demonstrate that the feature-oriented view of features from the users' perspective can be matched to the feature-oriented view of features in the IT side. This matching can serve to remove any ambiguities that may cause difficulties in the cases of system maintenance or system evolution, in particular when there are changes in requirements, which is to be expected when there is any business change