A Traceability Approach to Support Object-oriented Software

A Traceability Approach to Support Object-oriented Software Othman Mohd Yusop Centre for Advanced Software Engineering Universiti Teknologi Malaysia 54100 Jln Semarak, K. Lumpur othmanyusop@utm.my Dr. Suhaimi Ibrahim Centre for Advanced Software Engineering Universiti Teknologi Malaysia 54100 Jln Semarak, K. Lumpur suhaimiibrahim@utm.my ABSTRACT Traceability is a norm in software maintenance phase specifically for reverse engineering purposes. Software does change and evolve during maintenance or creation another version of software. Adding up new requirements or features onto existing software will cause introduction of new elements inside software artefacts (e.g. class diagrams, source codes, use cases and etc). Horizontal and vertical tracing are part of tracing techniques that were created to trace out links or dependencies among the artefacts. Therefore traceability approach has been become a way to resolve the tracing issues. This preliminary study has been carried out to look into possibility how a traceability approach could assist developer to capture a right abstraction of high level class diagram out of a given source code that is based on C++ programming language. Keywords Traceability approaches, traceability link, reverse engineering, software maintenance, software impact change. 1. INTRODUCTION Software maintenance consumes a big chuck of software expenditure. As stated by Bohner [1], forty percent of total software expenditure needs to be spent on software maintenance alone. Thus maintenance phase is one of a non-trivial phase in software development lifecycle. In order to identify potential impact on software artefacts due to changes during the development, a traceability approach is required. A traceability is defined by Gotel and Fikelstein [2] as the ability to describe and follow its life of a requirement, in both forward and backward direction; i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through period of ongoing refinement and iteration in any of these phases. This definition is strongly influenced by the requirement management community according to Aizenbud- Reshef et. al [3]. Capturing traceability link between code and elements in artefacts can be helpful in a number of tasks [4]: i) Program comprehension ii) Maintenance iii) Requirement Tracing iv) Impact Analysis v) Reuse of Existing Software and in facts these are possible domain of future research work. Numerous numbers of traceability approaches were introduced to combat problems of tracing back elements from source code in reverse engineering. Traceability Matrix, Keywords, Aspect Weaving, Information Retrieval, Scenario-Based [5][6][7], Eventbased [8][9], Process Centered, Design Pattern, Goal Centric [10] are some example of traceability techniques and many other more have been introduced to resolve aroused problems in reverse engineering. The demand to re-engineer legacy system has increased significantly with the shift toward web-based user interface [11]. Standard across these entire techniques has not been established and a single technique that capable to cope up issues in traceability such as non-functional requirement, functional requirement, elements dependency, visualizing links and etc has yet to be created. The traceability techniques are used for many reasons, such as managing evolutionary software change [8], impact analysis [9] [12], software architecture [5] and etc. The main focus for this research work would circulate around possibility of how traceability approach could support developers to capture highlevel design elements of design phase out of source codes. At this stage we are conducting studies on various existing traceability approaches and their usage during reverse engineering. Some open and commercial tools such as Columbus [23] and Visual Paradigm were used to provide better understanding of how reverse engineering is being done especially in extricating elements of artefacts out of a given source code that was written in C++ programming. Other tools such as Rigi and Doxygen are still under instigation. Most of these reverse engineering tools make used of Meta Object Facilities (MOF) such as extra Markup Language (XML) and XML Meta-data Interchange (XMI), which was developed by Object Modelling Group (OMG). 741

2. OBJECTIVES Studies on retrieving class diagram elements such as classes and its relationships namely associations, aggregations, dependencies, multiplicity and etc have been conducted by many researches such as [13][14][15][16] and many more are still under research works to provide comprehensive understanding in reverse engineering through traceability models and approaches. The objectives of this study are: i) To create traceability model that could assist developers to re-model high level class diagram out of C++ programming language based software system. ii) To automate manual tracing task on candidate impacted elements of artefacts by applying the model inside an automated tool. iii) To provide round-trip engineering capability during traceability process. Though the objectives were initially highlighted during this preliminary studies, but there are possibility that these objectives are subjected to change over the period of research work upon future findings and constraints. 3. LITERATURE REVIEW Traceability links define the relationships that exist between the various artefacts of software engineering process [25]. Artefacts composed of elements in requirement and design model, source codes, documentations and even behaviour of system itself is included. As defined by [24], an artefact is a piece of information produced or modified as part of the software engineering process while a link represents an explicit relationship defined between two artefacts. Literature studies have been carried out on various traceability techniques. These techniques are as follows: i) Event-Based Technique ii) Scenario-Based Technique iii) Goal Centric Technique iv) Matrices. Several other techniques pertaining to traceability capability would be updated as the research progress. 3.1 Event-Based Technique (EBT) EBT makes used of Event Notifier design pattern [17]. This pattern addresses problems related to handling change and provides a mechanism to minimizing the number of dependencies and interconnections between objects. Figure 1: Event-Based Traceability Model As depicted in Figure 1, EBT model is composed of Event Publisher, Event Server and Subscriber Handler. Event Publisher is a place where all type of requirements namely functional and non-functional is dependent to elements or objects. Whenever a significant change event occurs involving one of those requirements, an event notification message is published [18]. The notification message event is sent to Event Server, which the latter forwarded the notification to all dependent objects in artefacts. A Subscriber Handler receives the entire published event and handling them in a manner appropriate to both the artefact being managed and the type of message received. [8] When a change is introduced to a system, the traceability method must support impact analysis of the proposed change in order to avoid identification error. If the change is implemented, the traceability scheme supports the updating of impacted artefacts and their related links in order to avoid update errors. [9] EBT offers a solution to some of the difficulties inherent to maintaining accurate traceability by established loosely coupled traceability links through the use of publish-subscribe relationships between dependent objects. 3.2 Scenario-Based Technique Scenarios have been widely used and documented as a technique during requirements elicitation, especially with respect to the operator of the system [19]. Experience also shows that programmers use them to understand an already-built system, by asking how the system responds (component by component) to a particular input or operational situation [5]. The usage of scenarios depends on the software development phases which can be divided as follows [7]: i) Requirement scenarios is used to describe requirement at high-level abstraction which closer to stakeholders perspective. ii) Analysis scenarios is used to add details and internal functionality to requirement scenarios. iii) Design scenarios is used to describe architecture structure of the intended developed software system. iv) Architecture scenarios is used to describe details design of architecture structure, which comprises of components. v) Code scenarios is used to describe flow of event in implementation phase. 742

vi) Test scenarios appears in every phase of software development phases and is used to test the artefacts for software development. Each of scenarios for each phases describe steps of event occurred within the phases. Scenarios relationships can be used for traceability approach via ScenarioML [20]. Using the ScenarioML ones could possibly establishes tracing approach or method across entire software development phases. Here are sample of scenario-based analysis for several phases in software lifecycles: Figure 4: Goal-Centric Traceability During goal modelling phase, goal model is establish through requirement elicitation, specification and architectural design of system. It has to be agreed by various of stakeholders. Once goals are modelled, links are established between the functional model and prospect-impacted elements during impact detection which the latter is visualized using Softgoal Interdependency Graph (SIG) whereas functional model utilises UML class diagram. SIG in GCT is used to represent Non-functional requirements (NFRs). Figure 2: Scenario-Based Architecture Analysis: SAAM Method [5] If there is any impact during impact detection phase, goal model will be re-evaluated and goal evaluation report will be produced during goal analysis phase. Finally, stakeholders will examine the impact report and determine if change should be implemented or not during decision-making phase. 3.4 Matrices Technique A traceability matrix is a table that correlates any two baselined documents that require a many to many relationship to determine the completeness of the relationship. It is often used with highlevel requirements and detailed requirements of the software product to the matching parts of high-level design, detailed design, test plan, and test cases. Figure 3: Scenario-Based Analysis - Requirement Phase using ScenarioML [20] Common usage is to take the identifier for each of the items of one document and place them in the left column. The identifiers for the other document are placed across the top row. When an item in the left column is related to an item across the top, a mark is placed in the intersecting cell. The numbers of relationships are added up for each row and each column. This value indicates the mapping of the two items. Zero values indicate that no relationship exists. It must be determined if one must be made. Large values imply that the item is too complex and should be simplified. 3.3 Goal-Centric Technique (GCT) The technique utilises goal-centric approach to manage traceability in software changes during evolution. GCT gives an understanding to developers to capture impacted and prospect impacted changes in software upon implementing new functional requirement or non-functional requirement. [10] GCT is implemented through the four distinct phases of goal modelling, impact detection, goal analysis and decision making as Figure 2. To ease the creation of traceability matrices, it is advisable to add the relationships to the source documents for both backward 743

traceability and forward traceability. In other words, when an item is changed in one baselined document, it is easy to see what needs to be changed in the other. Below is sample of traceability matrix table [21]: 5. CONCLUSION AND SUGGESTED WORK During three months initial studies have shown many interesting and potential areas than can be explore and turn into research topic. Since the idea of this study is to create a new traceability model plus a tool to visualize how tracing works from source code to high-level design, some of studied papers seem not to be contribution. In the next period of time, research work would focuses more specifically on backward and forward tracing in between implementation and design phases therefore the developed model is hopefully capable to provide round trip engineering between the phases. Table 1: Sample of Traceability Matrix (Requirement Traceability) 4. DISCUSSION/CRITICAL ANALYSIS OF LITERATURE Even though the study was focusing on the said techniques, but in regards to my current research, most of the techniques are applied and implemented in different area of application. Nevertheless the studies have brought some insight of how traceability approaches, models and techniques work in any phases of software development lifecycle. Thus it does help me to alleviate some excellent knowledge of traceability in pursuing my own research traceability model. During research studies on the existing techniques, there are some weaknesses and strength found on the techniques as mentioned in below table as provided by [22] Table 2: Evaluation of Selected Traceability Methods The table above gives a comparative study among techniques used in traceability. It is a good start for my research interest to explore furthers the best technique to resolve my intended topic in finding a new traceability model from source code to high-level class diagram. 6. ACKNOWLEDGMENTS Our thanks to ACM SIGCHI for allowing us to modify templates they had developed. 7. REFERENCES [1] S.A.Bohner 1991. Software Change Impact Analysis for Design Evolution. 67 Proceedings of the 8th International Conference on Software Maintenance and Re-engineering [2] Gotel, O., & Finkelstein, C. (1994). An analysis of the requirements traceability problem. In Requirements Engineering, 1994., Proceedings of the First International Conference on (pp. 94-101). [3] Aizenbud-Reshef, N., Nolan, B. T., Rubin, J., & Shaham- Gafni, Y. (2006). Model traceability. IBM Syst. J., 45(3), 515-526. [4] Antoniol, G., Canfora, G., Casazza, G., Lucia, A. D., & Merlo, E. (2002). Recovering Traceability Links between Code and Documentation. IEEE Trans. Softw. Eng., 28(10), 970-983. [5] Kazman, R., Abowd, G., Bass, L., & Clements, P. (1996). Scenario-Based Analysis of Software Architecture. IEEE Softw., 13(6), 47-55. [6] Egyed, A. (2001). A scenario-driven approach to traceability. In Proceedings of the 23rd International Conference on Software Engineering (pp. 123-132). Toronto, Ontario, Canada: IEEE Computer Society. [7] Naslavsky, L., Alspaugh, T. A., Richardson, D. J., & Ziv, H. (2005). Using scenarios to support traceability. In Proceedings of the 3rd international workshop on Traceability in emerging forms of software engineering (pp. 25-30). Long Beach, California: [8] Cleland-Huang, J., Chang, C. K., & Christensen, M. (2003). Event-Based Traceability for Managing Evolutionary Change. IEEE Trans. Softw. Eng., 29(9), 796-810. [9] Cleland-Huang, J., K. Chang, C., & C. Wise, J. (2003). Automating performance-related impact analysis through event based traceability. Requirements Engineering, 8(3), 171-182. doi: 10.1007/s00766-003-0175-z. [10] Cleland-Huang, J., Settimi, R., BenKhadra, O., Berezhanskaya, E., & Christina, S. (2005). Goal-centric 744

traceability for managing non-functional requirements. In Proceedings of the 27th international conference on Software engineering (pp. 362-371). St. Louis, MO, USA: [11] Muller, H., Jahnke, J., Smith, D., Margaret, Tilley, S., & Wong, K. (2000). Reverse engineering: a roadmap. In ICSE - Future of SE Track (pp. 60, 47). [12] S. Ibrahim and M. Munro. A requirements traceability to support change impact analysis. Asian Journal of Information Technology, 4(4):329 338, 2005. [13] Pierce, R., & Tilley, S. (2002). Automatically connecting documentation to code with rose. In Proceedings of the 20th annual international conference on Computer documentation (pp. 157-163). Toronto, Ontario, Canada: [14] Reverse Engineering of the UML Class Diagram from C++ Code in Presence of Weakly Typed Containers. (2001). In Proceedings of the IEEE International Conference on Software Maintenance (ICSM'01) (p. 376). IEEE Computer Society. [15] Richner, T., & Ducasse, S. (1999). Recovering High-Level Views of Object-Oriented Applications from Static and Dynamic Information. In Proceedings of the IEEE International Conference on Software Maintenance (p. 13). IEEE Computer Society. [16] Grechanik, M., McKinley, K. S., & Perry, D. E. (2007). Recovering and using use-case-diagram-to-source-code traceability links. In Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering (pp. 95-104). Dubrovnik, Croatia: [17] S. Gupta, J. Hartkopf, and S. Ramaswamy, Event Notifier: A Pattern of Event Notification Java Report, vol. 3, no. 7, 1998, available online athttp://www.users.qwest.net/~hartkopf notifier. [18] Huang, J. (2002). Robust requirements traceability for handling evolutionary and speculative change. University of Illinois at Chicago. [19] Gough, P. A., Fodemski, F. T., Higgins, S. A., & Ray, S. J. (1995). Scenarios-an industrial case study and hypermedia enhancements. In Proceedings of the Second IEEE International Symposium on Requirements Engineering (p. 10). IEEE Computer Society. [20] Alspaugh, T. A. 2005. Temporally Expressive Scenarios in ScenarioML. Tech. Rep. UCI-ISR-05-06, Institute for Software Research, University of California, Irvine. [21] Roubtsov, S., & Heck, P. (2006). Use Case-Based Acceptance Testing of a Large Industrial System: Approach and Experience Report. In Proceedings of the Testing: Academic \& Industrial Conference on Practice And Research Techniques (pp. 211-220). IEEE Computer Society. [22] Cleland-Huang, J. (2005). Toward improved traceability of non-functional requirements. In Proceedings of the 3rd international workshop on Traceability in emerging forms of software engineering (pp. 14-19). Long Beach, California: [23] Beszédes, Á., Ferenc, R., & Gyimóthy, T. (2005). Columbus: A reverse engineering approach. IN STEP 2005, 93--96. doi: 10.1.1.80.6933. [24] Ramesh, B., & Jarke, M. (2001). Toward Reference Models for Requirements Traceability. IEEE Trans. Softw. Eng., 27(1), 58-93. [25] Sengupta, S., Kanjilal, A., & Bhattacharya, S. (2008). Requirement Traceability in Software Development Process: An Empirical Approach. In Rapid System Prototyping, 2008. RSP '08. The 19th IEEE/IFIP International Symposium on (pp. 105-111). 745