This research looks at architectural views of software and how they can be used to effectively evolve software systems over time. One specific stream of the research here looks at the consistency between the software architecture, as defined by the architect, and the software architecture as realised by the development team during the system’s implementation. Often these architectures will diverge, if not before initial deployment, then during subsequent evolution of the software system over time. This divergence can mean that the requirements that the architect tried to address (with his/her architecture) are not completely fulfilled which can result in general team confusion: since the architecture, as stated in the documentation, is inconsistent with the running system. This work aims to address and resolve these inconsistencies.

Another stream of research work looks at feature-oriented views of software systems, where a feature refers to a user-observable functionality of the system. One goal here, is to map features to the code that implements them: a core component of software comprehension and thus, software maintenance.  This is referred to as Feature Location (FL). Another goal is to generate feature-based views of the system, identifying the inter-feature dependencies and thus allowing, for example, the de-bloating of systems that have legacy or seldom-used features, without breaking the remaining features.

 

Impact story
  • ACI’s collaboration with Lero/UL in the area of feature location was cited as a core factor in their decision to open a state-of-the-art data centre in Limerick with 50+ new jobs;
  • Our prototype tool (JITTAC) in the area of software-architecture violation detection has been successfully trialled and used in companies like IBM, FINEOS, ACI, Information Mosaic and Fidelity Investments;
  • Given the importance of FL, a large number of Techniques (FLTs) to support software developers in this endeavour have been proposed. In our review of empirical evaluations of these FLTs, we have found that they are insufficient for purpose, where “purpose” is considered as allowing practitioners to select the best FLT for their context: 91% of the 152 paper reviewed propose new FLTs and, while the majority of these are evaluated, less than 20% are evaluated against a standard state-of-the-art FLT technique, making it impossible to compare effectiveness across FLTs. In addition >60 different evaluation measures, >30 different gold-standard benchmarks and >250 different software systems have been used in these evaluations, making impossible any meaningful comparison across techniques.  An alternative is to replicate the FLTs for new comparative studies, but our review suggests that over 40% of the papers where FLTs are presented, provide insufficient detail to replicate the FLT process. Our research will propose reporting guidelines that will allow practitioners select appropriate FLTs.

Case study

In IBM, JITTAC (demonstration: http://arc.lero.ie/jittac/) was used to partition the User Interface from their Learning Management System (LMS), so that it could be integrated into Workplace Collaborative Learning. The programmer using the tool said: “I did try this same job 2 months ago and gave up after two weeks” (This time, including code refactoring, it took 3.5 hours)…“Basically, I have what I always wanted: The LMS doesn’t even know the web component exists”. The architect, after reviewing the work, said: “all communication could potentially happen over a web service”….“that’s good, well done, there’s not an awful lot else to say…its right”

Based on this initial experience with the tool, further use took place during the re-development of IBM’s Domino Application Portlet (DAPs) application. Specifically they regarded the current implementation as a “spaghetti of code” and had decided to redevelop it, using our approach to preserve its architecture during implementation. Over its 1.6 year re-development, JITTAC was used 6 times to periodically check its architectural degradation. The approach did not eliminate architectural inconsistences: some inconsistencies were introduced because the development team did not want to touch some of the legacy components, and some were allowed as they were considered trivial. But the team knew of these violations going forward and could quantify them to management.

Later we trialled an improved version of the tool in 4 financial services companies in Ireland, over 5 commercial software systems (in total). The tool was positively received and was mostly used to assess the layering of these systems and the degree to which developers programmed to interfaces. They found that the tool’s facility for interactive feedback on the changes they made to the architectural model was really valuable, allowing them to virtually assess refactorings before they carried those refactorings out. Quotations from the participants include:

“It gives us a very sense of what has actually happened. It has always been very difficult to visualize or internalize this. This has been enormously interesting, it is always impossible to get this kind of metrics which we are getting here.”

"Interface in wrong package... OK, let’s look at what would change if we moved it (drags a class from the package explorer to an existing interface vertex)... its fixed it. …Oh really cool.... that's really cool“

"aha.. a circular dependency: that‟s why (the class was placed in what he thought was an inappropriate location)"

In terms of FL, a year 1 prototype (Y1P) tool was developed (demonstration: http://arc.lero.ie/flints/)  This demonstration’s focus is coverage of the Y1P’s functionality, and is not a demonstration of the tool’s meaningful use.

Due to our commercial partner’s confidentiality concerns this demonstration is focused on open source software, but the prototype has been used by 6 developers in our partner’s organization. The Y1P focused on expert developers: developers who know the software system well. We have just finished expanding the prototype to its year 2 (Y2P) instantiation and that version aims to address less expert users, thus widening the user-pool significantly.

  

Related Publications
  • Buckley J., Ali N., English M., Rosik J., and Herold S.. (2015). "Real-Time Reflexion Modelling in Architecture Reconciliation: A Multi Case Study". Information and Software Technology. Vol 61, pp: 107-123 DOI: 10.1016/j.infsof.2015.01.011.
  • Sharif K.Y., English M., Ali N., Exton C., Collins J.J., Buckley J.. (2015). “An  Empirically-Based Characterization and Quantification of Information Seeking through Mailing Lists During Open Source Developers' Software Evolution”. Information and Software Technology. 57(1) pp 77-94. DOI: 10.1016/j.infsof.2014.09.003.

Meet the Expert -

 

Dr. Jim Buckley

   To contact Jim or find out more information about his research and publications visit his profile here.