Frank J. Mitropoulos

Aspect mining using Self-Organizing Maps with method level dynamic software metrics as input vectors

A major impediment to program comprehension, maintenance and evolvability is the existence of crosscutting concerns scattered across different modules tangled with implementations of other concerns. Presence of crosscutting concerns in software systems can lead to bloated and inefficient software systems that are difficult to evolve, hard to analyze, difficult to reuse and costly to maintain. This paper shows that clustering based on easily extractable software features derived through method calls, parameter sharing and method interactions represented as dynamic metrics can be used to determine code scattering and or tangling, thereby providing a steppingstone towards identifying crosscutting concerns leading to mining of possible aspect candidates. A three-step approach is used in the Aspect Mining methodology introduced in this paper. In the first step, two legacy programs were dynamically traced, and data representing interaction between code fragments were collected. In the second step, metrics were formulated from the collected data and submitted as input to Self Organizing Maps for clustering. In the third step, the obtained clusters were mapped against the test programs in order to identify code scattering and tangling symptoms, leading to identification of aspect candidates. Finally viable validation methodologies were applied to assess performance, and establish the validity of the methodologies used. Results obtained in this paper are found to have matched or exceeded results obtained in other existing Aspect Mining methods

NORPLAN: Non-functional Requirements Planning for agile processes

Agile software development and project management methodologies, such as Scrum and Extreme Programming, have become very popular in quickly delivering quality Functional Requirements (FRs). However, agile project management methodologies have not adequately captured planning and prioritization activities for crosscutting concerns and non-functional requirements in agile practices. This research proposes project management and requirements quality metrics that would be used to design a risk-driven algorithm to prioritize and plan an improved requirements implementation sequence that is suitable for agile software development methodologies. Unlike the overly simplistic business value prioritization scheme used in methodologies such as Scrum, Non-functional Requirements Planning (NORPLAN) proposes two additional prioritization schemes, namely, Riskiest-Requirements-First and Riskiest-Requirements-Last for improved yet more agile planning for release and sprint cycles using a risk-driven approach. The approach is validated through visual simulation and a case study.

Visualization and scheduling of non-functional requirements for agile processes

Agile software development and project management methodologies, such as Scrum and Extreme Programming, have become very popular in quickly delivering quality Functional Requirements (FRs). However, agile project management methodologies have not adequately captured planning and visualization activities for crosscutting concerns and non-functional requirements in agile practices. This research proposes a planning and visualization framework that would be used to schedule software non-functional requirements implementations while utilizing agile software development and project management agile techniques. The approach is validated through visual simulation and a case study. Results showed that utilizing a risk-driven agile planning approach that involve non-functional requirements resulted in shortening the project schedule by one to two months over a traditional “Highest-Business-Value-First” agile scheduling technique.

Capturing, eliciting, predicting and prioritizing (CEPP) non-functional requirements metadata during the early stages of agile software development

Agile software engineering has been a popular methodology to develop software rapidly and efficiently. However, this methodology often considers Functional Requirements (FRs) due to the nature of agile software development and strongly neglects Non-Functional Requirements (NFRs). Neglecting NFRs has negative impacts on software products that have resulted in poor quality and higher cost to fix problems in later stages of software development. This research proposes a study to effectively gather NFRs metadata from software requirement artifacts such as documents and images. This will be accomplished by reducing false positives to include NFRs in the early stages of software requirements gathering along with FRs. In addition, this study will use historical trending to predict additional NFRs that are overlooked by architects and can be included along with FRs in the early stages of agile software development. Furthermore, prioritization of NFRs using existing FRs methodologies is important to stakeholders as well as software engineers in delivering quality software. This research builds on prior studies by specifically focusing on NFRs during the early stages of agile software development. The goal of this study is to improve upon prior studies of NFRs in order to provide effective techniques to prioritize and predict NFRs during the early stages of agile software development and the impacts that NFRs have on the software development process.

The NERV methodology: A lightweight process for addressing non-functional requirements in agile software development

Agile software development has become very popular around the world in recent years, with methods such as Scrum and Extreme Programming (XP). Literature suggests that functionality is the primary focus in Agile processes while non-functional requirements (NFRs) are either ignored or ill-defined. However, for software to be of good quality both functional requirements (FRs) and NFRs need to be taken into consideration; lack of attention to NFRs has been documented to be the cause of failure for many software projects. Hence special attention needs to be focused on NFRs in Agile software development. Requirements elicitation, implementation in design, development, and validation are important activities of software development. Agile has good processes to elicit functional requirements that are captured as user stories. However, NFRs elicitation has not been given enough attention within Agile processes. Additionally, reasoning and validating of NFRs have been lacking. This research proposes the “NERV Methodology: Nonfunctional Requirements Elicitation, Reasoning, and Validation in Agile Processes.” Current results show the artifacts developed in this research can potentially help software development organizations address NFRs in early Agile processes.

Using aspects for testing nonfunctional requirements in object-oriented systems

Software testing is one of the most time consuming activities in the software development cycle. Current research suggests that aspect-oriented programming (AOP) can enhance testing and has the potential to be more effective than macros or test interfaces. There are two major weaknesses when using aspects which are the inability of aspect code to be woven at all execution points and the lack of direct support for interweaving aspects with other aspects. In this paper we address the two major weaknesses and provide a means to overcome them. In addition, current research has focused only on using aspects to test functional requirements (FRs) and paid little attention to nonfunctional requirements (NFRs). In this paper we perform a feasibility study of using aspects to test NFRs which is based on two categorizations of NFRs. The first categorization splits NFRs into four types namely functionally restrictive, additive restrictive, policy restrictive, and architecturally restrictive and the second categorization splits the NFRs into two types: operational and nonoperational. These categorizations would serve as an initial point for developing frameworks or methodologies for testing NFRs with aspects.

eCAD: a knowledge-based course engineering system

Colleges and universities have increasingly migrated towards utilizing the World Wide Web to convey at least a part and, in many cases, their entire curricular offering. Despite this trend, there is inadequate support for the professors responsible for restructuring the courses they have refined over a career in the classroom for delivery via the Web. Teachers who are expert in their subject area and masters of their craft when in a classroom find themselves in the uncomfortable position of having to relearn how to teach in a new environment with little or no support. The process of planning and developing a course for delivery in an online environment is, in many significant aspects, analogous to the processes required to develop a software system. Both situations require the developer to manage resources through a series of steps with the goal of designing a product that effectively utilizes the computer to solve a problem. The procedures and tools used in software engineering to manage software system development, therefore, offer promise for developing online courses. Computer aided software engineering (CASE) tools are of special interest by virtue of the support afforded the development process through computerization. This paper offers an architectural overview of a knowledge-based, course engineering system: eCAD (electronic Course Analysis & Design). The requirements for the system, the manner in which those criteria were developed and validated, and system design are detailed. A working prototype is also presented.

Survey and analysis of quality measures used in aspect mining

Aspect mining investigates effective ways of finding crosscutting concerns in existing non-aspect oriented software. These crosscutting concerns can then be refactored into aspects to reduce the systems complexity and make it easier to understand, maintain, and evolve. There have been numerous studies introducing different aspect mining techniques, but they used different quality measures to evaluate their techniques. This paper consolidates a list of these existing quality measurements, discusses how they differ from each other, identifies some examples of how they have been used in previous aspect mining studies, and conducts an analysis of the commonly used metrics for aspect mining clustering. The metrics are compared using real and sample clustering results, identifying their similarities and differences, as well as their strengths and weakness.

Construction and analysis of vector space models for use in aspect mining

A software system is designed so that its concerns are as independent as possible. Concerns upon which other concerns depend are called crosscutting concerns, examples of which are logging, authentication, and session management. Crosscutting concerns in a software system have the potential to increase the number of defects over time as the system is evolved. Aspect-oriented programming provides an additional layer of abstraction to the object-oriented programming paradigm for the purpose of separating concerns. The search for crosscutting concerns is referred to as aspect mining. Previous aspect mining algorithms used aggregated metric values as components in the vector space model. In this paper a new method for constructing vector space models is proposed that attempts to retain the detail present in the relationships between the elements of a software application. This is done through the use of pattern matrices derived from the non-aggregated metrics. The non-aggregated vector space models are then used in a clustering-based aspect mining algorithm and their performance is evaluated. The results show that this new approach to constructing vector space models is a viable one but needs further investigation. Issues with current measures for evaluating clustering-based aspect mining algorithms are highlighted and directions for further research are given.

Refining and reasoning about nonfunctional requirements

Nonfunctional requirements (NFR) must be addressed early in the software development cycle to avoid the cost of revisiting those requirements or re-factoring at the later stages of the development cycle. Methods and frameworks that identify and incorporate NFR at each stage of development cycle reduce this cost. The methodology used in this work for refining and reasoning about NFR is based on the NFR framework. This work identifies four NFR types and provides the methodology for developing domain specific NFR by using techniques for converting the requirements into design artifacts per NFR type. The contribution is four NFR types: Functionally Restrictive, Additive Restrictive, Policy Restrictive, and Architecture Restrictive and the software engineering process that provides specific refinements that result in unique architectural and design artifacts. By applying the same functional requirement focus to the different NFR domains it enhances the development process and promotes software quality attributes such as composability, maintainability, evolvability, and traceability.