140 likes | 243 Views
Knowledge-oriented Maintenance at the University of Ottawa. Timothy C Lethbridge KOM 2004 - Banff. The Knowledge-Based Reverse Engineering Group at the University of Ottawa. Formed by Tim Lethbridge in 1994 Original focus was strictly knowledge-based work We still do some of that
E N D
Knowledge-oriented Maintenanceat the University of Ottawa Timothy C Lethbridge KOM 2004 - Banff
The Knowledge-Based Reverse Engineering Group at the University of Ottawa • Formed by Tim Lethbridge in 1994 • Original focus was strictly knowledge-based work • We still do some of that • But our focus has broadened to “tools for helping people deal with complexity”
Project 1: Bullding a Knowledge Base to help software engineering of ObjecTime • History • We had built a series of knowledge management systems (CODE2, CODE4) in the 1989-1994 period • We were working with Nortel to help them grapple with the complexity in their software design tools • We built a KB interactively with their developers • The process helped iron out key concepts • Later, this tool span off as a separate company • Incorporated into Rational, and later into IBM • Reference • My PhD thesis: http://www.site.uottawa.ca/~tcl/thesis_html/thesis_ToC.html
Project 2: A lightweight knowledge base for maintainers • Contained • An ontology of concepts relating to a large telecom system at Mitel • Basic definitions and cross references • Uses • Available for exploration to help new hires learn the system • Hooked to ‘intelligent search’ system to help search for concepts in source code • Hooked to browsing system: When browsing code, maintainers could follow links from words in comments
Project 2 - continued • Experience building the KB: • Done quickly with very little work • Step 1: Scan source code comments and key documents for words and phrases • Step 2: Use a multi-phase ranking/voting UI to have project team members prioritize, organize and categorize concepts • Deployed: • In TkSee at Mitel - used by 15-20 maintainers
Project 2 - continued • References: • Sayyad-Shirabad, J., Lethbridge, T.C. and Lyon, S, (1997, May), "A Little Knowledge Can Go a Long Way Towards Program Understanding", 5th International Workshop on Program Comprehension, Dearborn, MI, pp. 111-117 • Liu, H., and Lethbridge, T.C. (2002), “Intelligent Search Methods for Software Maintenance”, Information Systems Frontiers, 4, 4, pp. 409-423.
Project 3: Mining a maintenance records to find relevant software entities • Premise • When maintaining software, maintainers are often not aware of the files, classes, methods that need to be modified • We want to create an advisor that will study what you are modifying, and suggest other things that might need modifying • This can be done by systematic impact analysis, but we want to try an alternative approach
Project 3 - continued • Approach • Extract all the software entities that have been modified together over several years in the system • Found in the change management system • Extract a wide variety of attributes of all software entities • Apply machine learning to derive a model that predicts, for any pair, whether when modifying one element, you should look at the other • Results • After a major PhD project, we have very good prediction tools
Project 3 - continued • References • Sayyad Shirabad, S, Lethbridge, T.C. and Matwin, S. (2004) “Mining Software the Repository of a Legacy Telephony System”, MSR 2004: International Workshop on Mining Software Repositories, in conjunction with ICSE 2004, Edinburgh Scotland, May, IEE Press • Sayyad Shirabad, J., Lethbridge, T.C. Matwin, S. (2003) “Applying Data Mining to Software Maintenance Records”, proc CASCON 2003, Toronto, October, IBM, in ACM Digital Library, pp. 136-148. • Sayyad Shirabad, J, Lethbridge, T.C., Matwin, S., (2003) “Mining the Maintenance History of a Legacy Software System”, International Conference on Software Maintenance (ICSM), Amsterdam, IEEE Computer Society, pp. 95-104. • Jelber Sayyad’s PhD thesis: http://www.site.uottawa.ca/~tcl/gradtheses/jsayyad/
Project 4 - Proposed work to remodel the UML 2 spec and metamodel in a KB • Premise • The UML 2.0 Spec is confusing and inconsistent • Software engineers could make better use of models of they could have a more consistent and better specified modelling language and tools • UML and modelling is a knowledge-rich area, ready for knowledge management • Status • We are initiating this work with IBM
What knowledge is most important to a maintainer • Simple, navigable facts about their system • But more than just code knowledge • Knowledge about: • The domain • The requirements • The conceptual framework • The terminology used • Simplicity is key
How can this knowledge be best captured, and from where? • Simple tools • Extract terminology from documentation and the system • Have software engineers rank and organize it • They can do 5000 concepts in a day! We did it!
How can we make best use of this knowledge? • In a code exploration tool
This presentation will be at: • http://www.site.uottawa.ca/~tcl/presentations/kom-banff-lethbridge.ppt • Thank-you!