Crosscutting, what is and what is not? A Formal definition based on a Crosscutting Pattern

Crosscutting is usually described in terms of scattering and tangling. However, the distinction between these concepts is vague, which could lead to ambiguous statements. Sometimes, precise definitions are required, e.g. for the formal identification of crosscutting concerns. We propose a conceptual framework for formalizing these concepts based on a crosscutting pattern that shows the mapping between elements at two levels, e.g. concerns and representations of concerns. The definitions of the concepts are formalized in terms of linear algebra, and visualized with matrices and matrix operations. In this way, crosscutting can be clearly distinguished from scattering and tangling. Using linear algebra, we demonstrate that our definition generalizes other definitions of crosscutting as described by Masuhara & Kiczales [21] and Tonella and Ceccato [28]. The framework can be applied across several refinement levels assuring traceability of crosscutting concerns. Usability of the framework is illustrated by means of applying it to several areas such as change impact analysis, identification of crosscutting at early phases of software development and in the area of model driven software development

Component Integration Metrics and Their Evaluation

Software Engineering (SE) has been described as the discipline devoted to the design, development, and use of computer software, covering not only the technical aspects of building software systems, but also management issues develops highly complex software. The crisis in SE, due to the lack of well-defined formal processes, has led to poorly designed products with high maintenance costs and whose behavior becomes unpredictable. Component Based Software Engineering (CBSE) is currently a preferred approach to system design to overcome the crisis of SE, since it promotes software re-use, facilitates adaptability and faster system development. A component provides a function or a set of related functions, which forms a reusable program building block that can be combined with other components to form an application. A component with qualities such as, reusability, testability, modularity, complexity, proper to communicate and stability reduces maintenance costs. The components thus integrated, should be able to interoperate so that an operational application that results in reduced maintenance costs can be composed with minimal effort. Metrics are used to measure a component\u27s quality factor and there are no good metrics available to validate their effectiveness, when components are integrated. Currently, the success of projects based on the CBSE methodology relies on experts who assess software components; however, their evaluation process involves parameters that may not be measured in practice. Existing traditional metrics are inappropriate since CBSE is aimed at improving interoperability and re-usability. Size metrics based on lines of code are not applicable as component sizes may not be known a priori. Furthermore, complexities that arise due to varying nature of facets and interfaces are not addressed by traditional metrics. This thesis addresses the evaluation of a series of metrics based on complexity, criticality and dynamic behavior, in order that component integration performance can be assessed. Three suites of metrics defined by various authors have been considered for evaluation so that one could choose the best metrics to measure an integrated environment. A suite of metrics proposed by Narasimhan and Hendradjaya are classified based on the attributes of: complexity, criticality and dynamic aspects. These metrics use graph-based connectivity to represent a system of integrated components. While the complexity metrics consider the packing density of integrated components and the interaction density among the components, criticality metrics reveal the extent of binding within each component in the system. Dynamic metrics have also been collected during the execution of an application and aid the process involved in testing and maintenance. Metric related data sets have been from several benchmark programs using instrumentation programs and key inferences have been obtained; these inferences include a systematic evaluation of quality of the various metrics. Two new metrics have also been provided towards assessing the stability of the application: one metric, namely CRIT instability, calculates the instability of each component, while the second new metric, namely CRIT inheritance,counts the number of components whose children exceeds a threshold value. Both these metrics are useful to assess the stability of the application and, in addition, to determine the components in a given application that needs to be redesigned. Future work will focus on the development of a metric evaluation suite to assess the system\u27s stability as a whole, considering the role of each component in an application

Assessing technical candidates on the social web

This is the pre-print version of this Article. The official published version can be accessed from the link below - Copyright @ 2012 IEEEThe Social Web provides comprehensive and publicly available information about software developers: they can be identified as contributors to open source projects, as experts at maintaining weak ties on social network sites, or as active participants to knowledge sharing sites. These signals, when aggregated and summarized, could be used to define individual profiles of potential candidates: job seekers, even if lacking a formal degree or changing their career path, could be qualitatively evaluated by potential employers through their online contributions. At the same time, developers are aware of the Web’s public nature and the possible uses of published information when they determine what to share with the world. Some might even try to manipulate public signals of technical qualifications, soft skills, and reputation in their favor. Assessing candidates on the Web for technical positions presents challenges to recruiters and traditional selection procedures; the most serious being the interpretation of the provided signals. Through an in-depth discussion, we propose guidelines for software engineers and recruiters to help them interpret the value and trouble with the signals and metrics they use to assess a candidate’s characteristics and skills