InvariantDiscovery - 272: Software Engineering Fall 2008...

Info iconThis preview shows pages 1–8. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: 272: Software Engineering Fall 2008 Instructor: Tevfik Bultan Lecture 16: Dynamic Invariant Discovery Specifications • We saw various specification techniques – contracts for classes • JML – object oriented design • OCL, Alloy – interfaces • Interface grammars, interface state machines • All these specification techniques help software developers to document the design decisions at a higher level of abstraction than the code Specifications • There is one problem with software specifications – Software developers do not like to write them! • I personally believe that it is all about cost/benefit ratio – If there is enough benefit in writing specifications • reduced development time, more reliable programs, etc. – then people will write specifications • Maybe current tools and techniques used in software development do not provide enough benefit for writing specifications – This may change in the future based on all the techniques and tools we discussed in this course Lack of Specifications • However, the fact remains, there is a lot of code out there with no specifications – maybe even no comments • What should we do about them? • You may say “Why do I care? I write detailed specifications when I develop software.” – There may be some code written by somebody else that you need to maintain, modify, or reuse • none of the original developers may still be around • there may not be any specifications • the specifications may not have been maintained with the software Reverse Engineering • Reverse engineering is the process of analyzing a subject system – to identify the system’s components and their inter-relationships, and – to create representations of the system in another form or at a higher level of abstraction • Examples – Producing call graphs or control flow graphs from the source code – Generating class diagrams from the source code • Two types of reverse engineering – Redocumentation : the creation or revision of a semantically equivalent representation within the same relative abstraction layer – Design recovery : involves identifying meaningful higher level abstractions beyond those obtained directly by examining the system itself Reverse Engineering • The main goal is to help with the program comprehension • Most of the time reverse engineering makes up for lack of good documentation • We already saw a reverse engineering technique (a design recovery technique): – Automated interface extraction Dynamically Discovering Likely Invariants • Today I will talk about another reverse engineering approach • References – ``Dynamically discovering likely program invariants to support program evolution,’’ Michael D. Ernst, Jake Cockrell, William G....
View Full Document

This note was uploaded on 10/04/2011 for the course CEN 5016 taught by Professor Workman,d during the Spring '08 term at University of Central Florida.

Page1 / 38

InvariantDiscovery - 272: Software Engineering Fall 2008...

This preview shows document pages 1 - 8. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online