Softwarearchäologie

Softwarearchäologie oder Quellcodearchäologie ist die Untersuchung von schlecht dokumentiertem oder undokumentiertem Untersuchung Legacy-Software Implementierungen als Teil von Software-Wartung.[1][2] Softwarearchäologie, benannt nach Analogie mit Archäologie,[3] Beinhaltet die Reverse Engineering von Softwaremodulen und der Anwendung einer Vielzahl von Tools und Prozessen zum Extrahieren und Verständnis der Programmstruktur und der Wiederherstellung von Designinformationen.[1][4] Die Softwarearchäologie kann dysfunktionale Teamprozesse aufzeigen, die schlecht gestaltete oder sogar nicht verwendete Softwaremodule erstellt haben, und in einigen Fällen kann absichtlich verschleiert werden.[5] Der Begriff wird seit Jahrzehnten verwendet,[6] und spiegelt eine ziemlich natürliche Metapher wider: Ein Programmierer, der den Legacy -Code liest, kann das Gefühl haben, dass er oder sie in der gleichen Situation wie ein Archäologe, der die Trümmer einer alten Zivilisation erkundet, befindet.[7]

Techniken

Ein Workshop zur Softwarearchäologie am 2001 Oopsla (Objektorientierte Programmierung, Systeme, Sprachen und Anwendungen) Konferenz identifizierte die folgenden Software-Archäologie-Techniken, von denen einige spezifisch sind. Objekt orientierte Programmierung:[7]

  • Skriptsprachen Erstellung statischer Berichte und zur Filterung der Diagnoseausgabe
  • Laufende Dokumentation auf HTML -Seiten oder Wikis
  • Synoptische Signaturanalyse, statistische Analyse und Softwarevisualisierung Werkzeug
  • Rückwärtsgutwerkzeuge
  • Verfolgung auf Betriebssystemebene über Binder oder Strace
  • Suchmaschinen und Tools zur Suche nach Schlüsselwörtern in Quelldateien
  • Ide Dateistöbern
  • Unit -Tests Frameworks wie Jung und Cppunit
  • API -Dokumentationsgenerierung unter Verwendung von Tools wie z. B. Javadoc und Doxygen
  • Debugger

Allgemeiner, Andy Hunt und Dave Thomas Beachten Sie die Bedeutung von Versionskontrolle, Abhängigkeitsverwaltung, Textindexierungswerkzeuge wie einen Blick und den Blick Swish-eund "[Zeichnen] eine Karte, während Sie beginnen, zu erkunden."[7]

Wie bei der echten Archäologie beinhaltet die Softwarearchäologie die Untersuchungsarbeit, um die Denkprozesse der eigenen Vorgänger zu verstehen.[7] Im oopla Workshop, Ward Cunningham schlug eine synoptische Signaturanalyse -Technik vor Geschweifte Klammern.[8] In gleicher Weise hat Cunningham vorgeschlagen, Programme in 2 Punkten zu sehen, um die Gesamtstruktur zu verstehen.[9] Eine andere am Workshop identifizierte Technik war die Verwendung von Aspekt-orientiertes Programmieren Werkzeuge wie Aspektj systematisch einführen Verfolgung Code, ohne das Legacy -Programm direkt zu bearbeiten.[7]

Netzwerk- und zeitliche Analysetechniken können die Muster kollaborativer Aktivitäten durch die Entwickler von Legacy -Software aufzeigen, die wiederum Aufschluss über die Stärken und Schwächen der produzierten Software -Artefakte geben können.[10]

Michael Rozlog von Embarcadero -Technologien Hat Softwarearchäologie als sechs Schritte-Prozess beschrieben, mit dem Programmierer Fragen wie "Was habe ich gerade geerbt?" und "Wo sind die gruseligen Abschnitte des Codes?"[11] Diese Schritte umfassen die Visualisierung, um eine visuelle Darstellung des Programms des Programms zu erhalten. Software -Metriken Um nach Design- und Stilverstößen zu suchen, verwenden Sie mit Verwendung Unit -Tests und Profilerstellung Suchen Sie nach Fehlern und Leistungs Engpässen und Zusammenstellen von Entwurfsinformationen, die durch den Prozess wiederhergestellt wurden.[11] Softwarearchäologie kann auch ein Service sein, der den Programmierern von externen Beratern zur Verfügung gestellt wird.[12]

Mitch Rosenberg von Infoventions.net, Inc. behauptet, dass das erste Gesetz der Softwarearchäologie (er nennt es Code oder Datenarchäologie):

Alles, was dort ist, gibt es aus einem bestimmten Grund, und es gibt 3 mögliche Gründe:

  1. Es musste früher dort sein, aber nicht mehr
  2. Es musste nie dort sein und die Person, die den Code schrieb, hatte keine Ahnung
  3. Es muss noch da sein und Sie haben keine Ahnung

Die Folge dieses "Gesetzes" ist, dass Sie den Code (oder Daten) nicht ändern sollten, bis Sie wissen, welcher Grund der Grund war.

Die Softwarearchäologie ist weiterhin ein Diskussionsthema auf neueren Software -Engineering -Konferenzen.[13]

Der Beruf von Programmierer -Archäologe Funktionen prominent in Vernor Vinge's Eine Deepness am Himmel. [14]

Siehe auch

Verweise

  1. ^ a b Robles, Gregorio; Gonzalez-Barahona, Jesus M.; Herraiz, Israel (2005). "Ein empirischer Ansatz zur Softwarearchäologie" (PDF). Poster -Verfahren der Internationalen Konferenz zur Software -Wartung.
  2. ^ Ambler, Scott W. "Agile Legacy -Systemanalyse und Integrationsmodellierung". Agilemodeling.com. Abgerufen 2010-08-20. Ohne genaue Dokumentation oder Zugriff auf sachkundige Personen kann Ihr letzter Ausweg möglicherweise darin bestehen, den Quellcode für das Legacy -System zu analysieren ... diese Bemühungen werden häufig als Softwarearchäologie bezeichnet.
  3. ^ Moyer, Bryon (4. März 2009). "Softwarearchäologie: Modernisierung alter Systeme" (PDF). Embedded Technology Journal.
  4. ^ Hopkins, Richard; Jenkins, Kevin (2008). "5. der mythische Metaman". Essen Sie den IT -Elefanten: Wechsel von Greenfield Development nach Brownfield. Addison-Wesley. p. 93. ISBN 978-0-13-713012-2.
  5. ^ Spinellis, Diomidis; Gousios, Georgios (2009). "2. Eine Geschichte von zwei Systemen § Mangel an Zusammenhalt". Schöne Architektur. O'Reilly. p. 29. ISBN 978-0-596-51798-4.
  6. ^ Eine frühe Diskussion ist Grass, Judith E. (Winter 1992). "Objektorientierte Designarchäologie mit CIA ++" (PDF). Computersysteme. 5 (1).
  7. ^ a b c d e Jagd, Andy; Thomas, Dave (März - April 2002). "Softwarearchäologie" (PDF). IEEE -Software. 19 (2): 20–22. doi:10.1109/52.991327.
  8. ^ Cunningham, Gemeinde (2001). "Signaturumfrage: Eine Methode zum Surfen unbekannter Code". Workshop -Positionserklärung, Softwarearchäologie: Verständnis großer Systeme, Oopla 2001.
  9. ^ Cook, John D. (10. November 2009). "Softwarearchäologie". Das Bestreben.
  10. ^ de Souza, Cleeidson; Froehlich, Jon; Dourish, Paul (2005). "Suchen Sie die Quelle: Software -Quellcode als soziales und technisches Artefakt" (PDF). Proceedings der International ACM Siggroup -Konferenz von 2005 zur Unterstützung der Gruppenarbeit. S. 197–206. doi:10.1145/1099203.1099239. ISBN 1595932232.
  11. ^ a b Rozlog, Michael (28. Januar 2008). "Softwarearchäologie: Was ist es und warum sollten sich Java -Entwickler kümmern?". java.sys-con.com.
  12. ^ Sharwood, Simon (3. November 2004). "Raiders des verlorenen Code". ZDNET.
  13. ^ Zum Beispiel die "32. ACM/IEEE International Conference on Software Engineering". Mai 2010..
  14. ^ Rees, Gareth (2013-06-12). "Softwarearchäologie und technische Schulden".

Externe Links