In the US Air Force there exist several systems for which design documentation does not exist. Chief reasons for this lack of system documentation include software having been developed several decades ago, natural evolution of software, and software existing mostly in its binary versions. However, the systems are still being used and the US Air Force would like to know the actual designs for the systems so that they may be reengineered for future requirements. Any knowledge of such systems lies mostly with its users and managers. A project was commissioned to recover designs for such systems based on knowledge of systems obtained from stakeholders by interviewing them. In this paper we describe our application of the NFR Approach, where NFR stands for Nonfunctional Requirements, to recover software design of a middleware system used by the Air Force called the Phoenix system. In our project we interviewed stakeholders of the Phoenix system, applied the NFR Approach to recover design artifacts, and validated the artifacts with the design engineers of the Phoenix system. Our study indicated that there was a high correlation between the recovered design and the actual design of the Phoenix system. 1. Introduction Design recovery in software systems involves obtaining design from artifacts such as code, system documentation, and execution environment, with the primary objectives being reduced maintenance costs, system enhancement, or system reengineering [1–3]. Design recovery is especially important for legacy systems where only a few software artifacts exist to aid their understanding: for example, there are systems that are decades old and will serve useful purposes if reengineered but whose only artifacts are limited documentation, a few stakeholders willing to share their experiences with the system, and the executable binary code [4]. Usual techniques for design recovery include code-based and domain knowledge-based techniques. Code-based techniques [4, 5] start with parsing the code and identifying elements and then obtain the design. In doing so an intermediate representation of the code is derived such as the hammock graphs, dependency graphs, or control flow graphs. However, as mentioned in [4], knowledge about architecture, design decisions, and design constraints cannot be fully obtained from code analysis alone. Domain knowledge-based techniques are used for program comprehension [6] that uses knowledge representation such as graphs and trees and apply classical reasoning techniques to retrieve design patterns; they are mostly used to augment
References
[1]
E. J. Byrne, “Software reverse engineering: a case study,” Software: Practice and Experience, vol. 21, no. 12, pp. 1349–1364, 1991.
[2]
E. J. Chikofsky and J. H. Cross, “Reverse engineering and design recovery: a taxonomy,” IEEE Software, vol. 7, no. 1, pp. 13–17, 1990.
[3]
D. E. Wilkening and K. Littlejohn, “Legacy software reengineering technology,” in Proceedings of the 15th AIAA/IEEE Digital Avionics Systems Conference, pp. 25–30, October 1996.
[4]
H. A. Muller, J. H. Jahnke, D. B. Smith, M. A. Storey, S. R. Tilley, and K. Wong, “Reverse engineering: a roadmap,” in Proceedings of the Conference on the Future of Software Engineering, pp. 47–60, 2000.
[5]
R. K. Keller, R. Schauer, S. Robitaille, and P. Page, “Pattern-based reverse-engineering of design components,” in Proceedings of the 21st International Conference on Software Engineering, pp. 226–235, May 1999.
[6]
T. J. Biggerstaff, “Design recovery for maintenance and reuse,” Computer, vol. 22, no. 7, pp. 36–49, 1989.
[7]
G. Canfora and M. Di Penta, “New frontiers of reverse engineering,” in Proceedings of the Future of Software Engineering Conference (FoSE '07), pp. 326–341, May 2007.
[8]
V. T. Combs, R. G. Hillman, M. T. Muccio, and R. W. McKeel, “Joint battlespace infosphere: information management within a C2 enterprise,” in Proceedings of the 10th International Command and Control Research and Technology Symposium, 2005.
[9]
L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos, Non-Functional Requirements in Software Engineering, Kluwer Academic Publishers, Boston, Mass, USA, 2000.
[10]
A. Vemulapalli and N. Subramanian, “Evaluating consistency between BPEL specifications and functional requirements of complex computing Systems using the NFR approach,” in Proceedings of the 4th International Systems Conference (SysCon '10), pp. 153–158, April 2010.
[11]
L. Chung and N. Subramanian, “Adaptable architecture generation for embedded systems,” Journal of Systems and Software, vol. 71, no. 3, pp. 271–295, 2004.
[12]
L. Chung and N. Subramanian, “Process-oriented metrics for software architecture adaptability,” in Proceedings of the 5th IEEE International Symposium on Requirements Engineering, pp. 310–311, August 2001.
[13]
N. Subramanian and L. Chung, “Software architecture adaptability: an NFR approach,” in Proceedings of the 4th International Workshop on Principles of Software Evolution (IWPSE '01), pp. 52–61, September 2001.
[14]
N. Subramanian, S. Drager, and W. McKeever, “Designing trustworthy software systems using the NFR approach,” in Emerging Trends in ICT Security, B. Akhgar and H. Arabnia, Eds., pp. 203–225, Elsevier, 2014.
[15]
N. Subramanian and L. Chung, “Representing and reasoning about agreements ... more agreeably,” Lus Gentium Journal, vol. 12, pp. 205–258, 2006.
[16]
M. Shaw and D. Garlan, Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall, 1996.
[17]
L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Addison-Wesley, Boston, Mass, USA, 2003.
[18]
P. Eeles and P. Cripps, The Process of Software Architecting, Addison-Wesley, New Jersey, NJ, USA, 2010.
[19]
H. A. Muller, M. A. Orgun, S. R. Tilley, and J. S. Uhi, “A reverse engineering approach to subsystem structure identification,” Journal of Software Maintenance, vol. 5, no. 4, pp. 181–204, 1993.
[20]
Y. Yu, Y. Wang, J. Mylopoulos, S. Liaskos, A. Lapouchnian, and J. C. S. Do Prado Leite, “Reverse engineering goal models from legacy code,” in Proceedings of the 13th IEEE International Conference on Requirements Engineering (RE '05), pp. 363–372, September 2005.
[21]
P. Tonella and A. Potrich, Reverse Engineering of Object Oriented Code, Springer, New York, NY, USA, 2005.
[22]
M. Lanza and S. Ducasse, “Polymetric views: a lightweight visual approach to reverse engineering,” IEEE Transactions on Software Engineering, vol. 29, no. 9, pp. 782–795, 2003.
[23]
T. Syst？, K. Koskimies, and H. Müller, “Shimba: an environment for reverse engineering Java software systems,” Software, vol. 31, no. 4, pp. 371–394, 2001.
[24]
M. Salah, S. Mancoridis, G. Antoniol, and M. Di Penta, “Towards employing use-cases and dynamic analysis to comprehend mozilla,” in Proceedings of the 21st IEEE International Conference on Software Maintenance (ICSM '05), pp. 639–642, September 2005.
[25]
B. S. Mitchell and S. Mancoridis, “On the automatic modularization of software systems using the bunch tool,” IEEE Transactions on Software Engineering, vol. 32, no. 3, pp. 193–208, 2006.
[26]
G. Scanniello, A. D’Amico, C. D’Amico, and T. D’Amico, “Architectural layer recovery for software system understanding and evolution,” Software: Practice and Experience, vol. 40, no. 10, pp. 897–916, 2010.
[27]
R. Fiutem, P. Tonella, G. Antoniol, and E. Merlo, “Cliche-based environment to support architectural reverse engineering,” in Proceedings of the IEEE Conference on Software Maintenance (ICSM '96), pp. 319–328, November 1996.
[28]
P. Tonella, G. Antoniol, R. Fiutem, and F. Calzolari, “Reverse engineering 4. 7 million lines of code,” Software, vol. 30, no. 2, pp. 129–150, 2000.
[29]
W. W. Cohen, “Recovering software specifications with inductive logic programming,” in Proceedings of the 12th National Conference on Artificial Intelligence, pp. 142–148, August 1994.
[30]
P. Dugerdil, “A reengineering process based on the unified process,” in Proceedings of the 22nd IEEE International Conference on Software Maintenance (ICSM '06), pp. 330–333, September 2006.
[31]
A. Cimitile, A. De Lucia, G. A. Di Lucca, and A. R. Fasolino, “Identifying objects in legacy systems using design metrics,” Journal of Systems and Software, vol. 44, no. 3, pp. 199–211, 1999.
[32]
G. A. D. Lucca, A. R. Fasolino, F. Pace, P. Tramontana, and U. de Carlini, “WARE: a tool for the reverse engineering of web applications,” in Proceedings of the 6th European Conference on Software Maintenance and Reengineering, pp. 241–250, 2002.
[33]
N. Subramanian, S. Drager, and W. McKeever, “Engineering a trustworthy software system using the NFR approach,” in Proceedings of the Systems and Software Technology Conference, Salt Lake City, Utah, April 2012.
[34]
L. Chung, S. Supakkul, N. Subramanian et al., “Goal-oriented software architecting,” in Relating Software Requirements and Software Architectures, pp. 91–110, Springer, 2011.
[35]
D. Gross and E. Yu, “From non-functional requirements to design through patterns,” Requirements Engineering, vol. 6, no. 1, pp. 18–36, 2001.
[36]
M. Siff and T. Reps, “Identifying modules via concept analysis,” IEEE Transactions on Software Engineering, vol. 25, no. 6, pp. 749–768, 1999.
[37]
“Unified Modeling Language (UML),” http://www.uml.org/.
[38]
D. C. Schmidt, “Middleware for real-time and embedded systems,” Communications of the ACM, vol. 45, no. 6, pp. 43–48, 2002.
[39]
T. Erl, SOA Design Patterns, Prentice Hall, New Jersey, NJ, USA, 2009.
[40]
D. Sprott and L. Wilkes, “Understanding Service-Oriented Architecture,” 2004, http://msdn.microsoft.com/en-us/library/aa480021.aspx.
[41]
M. Elkstein, “Learn REST: A Tutorial,” http://rest.elkstein.org/.
[42]
“SpringSource,” http://spring.io/.
[43]
C. Hsu - and B. A. Sandford, “The Delphi technique: making sense of consensus,” Journal of Practical Assessment, Research, and Evaluation, vol. 12, no. 10, 2007.
