Software archeology

People remember how things work, and have knowledge about particular software system (often undocumented) that can only be acquired in many years working with multiple version of the software system. Sometimes they record this information somewhere and store their records somewhere but mostly they don't. When they leave information is lost. This is called corporate amnesia. The same things happen with documentation can be in formats no longer readable. Once I have to deal with software documentation that was written on an old mainframe disk and it did not exist in any other form. Over the 45 years since program were written corporate memory was wiped out. Yes, the programs work and brings money to the company; some minimal maintenance is performed, and the highly sophisticated experts know that they need to make it work.

Similarly one of my friends once have to deal with PDP11 as programs for it were too important to abandon this hardware platform. But those are extreme cases.

Like true archaeology, software archaeology involves investigative work to understand the thought processes of one's predecessors.^[7] At the OOPSLA workshop, Ward Cunningham suggested a synoptic signature analysis technique which gave an overall "feel" for a program by showing only punctuation, such as semicolons and curly braces.^[8] In the same vein, Cunningham has suggested viewing programs in 2 point font in order to understand the overall structure.^[9] Another technique identified at the workshop was the use of aspect-oriented programming tools such as AspectJ to systematically introduce tracing code without directly editing the legacy program.^[7]

Network and temporal analysis techniques can reveal the patterns of collaborative activity by the developers of legacy software, which in turn may shed light on the strengths and weaknesses of the software artifacts produced.^[10]

Michael Rozlog of Embarcadero Technologies has described software archaeology as a six-step process which enables programmers to answer questions such as "What have I just inherited?" and "Where are the scary sections of the code?"^[11] These steps, similar to those identified by the OOPSLA workshop, include using visualization to obtain a visual representation of the program's design, using software metrics to look for design and style violations, using unit testing and profiling to look for bugs and performance bottlenecks, and assembling design information recovered by the process.^[11] Software archaeology can also be a service provided to programmers by external consultants.^[12]

Mitch Rosenberg of InfoVentions.net, Inc. claims that the first law of software archaeology (he calls it code or data archaeology) is:

Everything that is there is there for a reason, and there are 3 possible reasons:

The corollary to this "law" is that, until you know which was the reason, you should NOT modify the code (or data).

Software archaeology has continued to be a topic of discussion at more recent software engineering conferences.^[13]

Software architecture recovery is a set of methods for the extraction of architectural information from lower level representations of a software system, such as source code. The abstraction process to generate architectural elements frequently involves clustering source code entities (such as files, classes, functions etc.) into subsystems according to a set of criteria that can be application dependent or not. Architecture recovery from legacy systems is motivated by the fact that these systems do not often have an architectural documentation, and when they do, this documentation is many times out of synchronization with the implemented system.

Approaches[edit]

Most approaches to software architecture recovery has been exploring the static analysis of systems. When considering object-oriented software, which employs a lot of polymorphism and dynamic binding mechanisms, dynamic analysis becomes an essential technique to comprehend the system behavior, object interactions, and hence to reconstruct its architecture. In this work, the criteria used to determine how source code entities should be clustered in architectural elements are mainly based on the dynamic analysis of the system, taking into account the occurrences of interaction patterns and types (classes and interfaces) in use-case realizations.

NEWS CONTENTS

Old News ;-)

Softpanorama May the source be with you, but remember the KISS principle ;-)	Home	Switchboard	Unix Administration	Red Hat	TCP/IP Networks	Neoliberalism	Toxic Managers
	(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix

Top Visited <p>Your browser does not support iframes.</p>					Switchboard
					Latest
					Past week
					Past month

Software archeology

Approaches[edit]

NEWS CONTENTS

Old News ;-)

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

Top articles

Sites

Etc