An empirical study of aspect-oriented metrics

Metrics for aspect-oriented software have been proposed and used to investigate the benefits and the disadvantages of crosscutting concerns modularisation. Some of these metrics have not been rigorously defined nor analytically evaluated. Also, there are few empirical data showing typical values of these metrics in aspect-oriented software. In this paper, we provide rigorous definitions, usage guidelines, analytical evaluation, and empirical data from ten open source projects, determining the value of six metrics for aspect-oriented software (lines of code, weighted operations in module, depth of inheritance tree, number of children, crosscutting degree of an aspect, and coupling on advice execution). We discuss how each of these metrics can be used to identify shortcomings in existing aspect-oriented software. (C) 2012 Elsevier B.V. All rights reserved.CNPq [140046/06-2]; Project CNPQ-PROSUL [490478/06-9]; Capes-Grices [2051-05-2]; FAPERGS [10/0470-1]; FCT MCTESinfo:eu-repo/semantics/publishedVersio

Inquiring the usage of aspect-oriented programming: an empirical study

International audienceBack in 2001, the MIT announced aspect-orientedprogramming as a key technology in the next 10 years.Nowadays, 8 years later, AOP is not widely adopted.Several reasons can explain this distrust in front ofAOP, and one of them is the lack of robust tools foranalysis, testing and maintenance. In order to developdedicated solutions for assisting the development withAOP, and increase its adoption, we need to understandhow it is actually used. In this paper we analyze 38aspect-oriented open source projects with respect tothe impact of aspects on the projects, and to coverageof the language features. This reveals that AOP iscurrently used in a cautious way. This work is a firststep to built support and development tools dedicatedto actual practices for AOP, based on empirical usage profiles

Missing Requirements Information and its Impact on Software Architectures: A Case Study

[Context & motivation] In the development of large, software-intensive systems, the system’s requirements are seldom, if ever, concluded upon prior to commencing with systems architecture. Research shows that, in order to manage development and domain complexities, instances of requirements engineering (RE) and systems architecting (SA) processes tend to inter-weave. [Question/problem] However, missing requirements information can cause one to create (or recreate) the needed information during different SA activities. While backtracking in the software development process is known to be costly, the costs associated with missing requirements in the SA process have not been investigated empirically. [Principal ideas/results] We thus conducted a case study where we investigated to what extent requirements or requirements attributes’ information found missing during the SA process and impact of those missing information on SA in terms of effort. The study involved five architecting teams that involve final year undergraduate and graduate students enrolled in the university course on SA, working on architecting a system falls under “banking” domain. Our result shows that, architects did find requirements and requirements attributes’ information missing while architecting. Among requirements information, architects found that, system functionality information, constraints information and system interaction (users/systems) information are missing in requirements at higher percentages. Within requirements’ attributes, architects found requirements priority, dependency and rationale missing at higher percentages. It is also found that, out of total time spent on architecting the system, effort given to recreate missing requirements information is higher for group3 (21.5%), group1 (18%), and group2 (17%) other than group4 (12.37%) and group5(10.18%). [Contribution] The anticipated benefits of the findings are, it can motivate researchers to venture into other areas of software engineering (such as coding, testing, maintenance, etc.) from the view point of missing requirements information and its impact on those areas. This knowledge could help software practitioners to decide what kind of information need to take care of, during RE process, that could possibly ease SA process and later development phases. To the best of my knowledge, this is the first work which focuses on, to what extent requirements and requirements’ attributes information found missing during SA; characteristics and impact of those requirements missing information on SA process in terms of effort

How Lean Six Sigma and Agile principles optimize ITIL-based processes

Imagine the potential implications of an organization whose business and IT processes are well aligned and are capable of reactively and proactively responding to the external and internal changes. The Philips IT Infrastructure and Operations department (I&O) is undergoing a series of transformation activities to help Philips business keeping up with the changes. I&O would serve a critical function in any business sectors; given that the I&O’s strategy switched from “design, build and run” to “specify, acquire and performance manage”, that function is amplified. In 2013, I&O’s biggest transforming programme I&O Futures engaged multiple interdisciplinary departments and programs on decommissioning legacy processes and restructuring new processes with respect to the Information Technology Internet Library (ITIL), helping I&O to achieve a common infrastructure and operating platform (CI&OP). The author joined I&O Futures in the early 2014 and contributed to the CI&OP release 1, during which a designed model Bing Box and its evaluations were conducted through the lens of six sigma’s structured define-measure-analyze-improve-control (DMAIC) improvement approach. This Bing Box model was intended to firstly combine business and IT principles, namely Lean IT, Agile, ITIL best practices, and Aspect-oriented programming (AOP) into a framework. Secondly, the author implemented the modularized optimization cycles according to the defined framework into Philips’ ITIL-based processes and, subsequently, to enhance business process performance as well as to increase efficiency of the optimization cycles. The unique of this thesis is that the Bing Box model not only provided comprehensive optimization approaches and principles for business process performance, but also integrated and standardized optimization modules for the optimization process itself. The research followed a design research guideline that seek to extend the boundaries of human and organizational capabilities by creating new and innovative artifacts. The Chapter 2 firstly reviewed the current research on Lean Six Sigma, Agile, AOP and ITIL, aiming at identifying the broad conceptual bases for this study. In Chapter 3, we included the process of constructing the Bing Box model. The Chapter 4 described the adoption of Bing Box model: two-implementation case validated by stakeholders through observations and interviews. Chapter 5 contained the concluding remarks, the limitation of this research work and the future research areas. Chapter 6 provided the references used in this thesis.Master's thesissiirretty Doriast

Program Comprehension of Aspect-Oriented Programs

The aim of aspect-oriented development has been to address the issue of software reuse outside the domain of established object-oriented techniques within the challenging realm of similar cross-cutting concerns. By decoupling the concerns from the core functionality, aspect-oriented developed software results in a smaller code base and reduced code duplication. This decoupling though presents new challenges to the software development process. The process of separating concerns impacts the developers established engineering inclinations as well as existing, established notations, such as UML, that developers are familiar with utilizing for both designing and understanding the implemented software systems. This thesis will study the impact of aspect-oriented software development on programmers’ ability to comprehend the core system in addition to their comprehension of the aspect implementation