Reverse Engineering of Software Architecture
3 likes4,983 views
This document summarizes a presentation given by Mikael Lindvall and Dharma Ganesan of the Fraunhofer Center for Experimental Software Engineering Maryland on software architecture, reverse engineering, and analyzing legacy systems. The Fraunhofer Center develops techniques for analyzing the structure and behavior of legacy software using methods and tools. They have analyzed several large legacy systems, including NASA's Space Network and Core Flight Software. The presentation describes their model of software architecture and reverse engineering, which involves creating views of the runtime and development architecture from source code. It also gives an example of how they analyzed the Common Ground System, a ground system for NASA missions, by visualizing its actual architecture based on source code.
Reverse Engineering of Software Architecture
- 1. Software Architecture in Evolution and Reverse Engineering of Legacy systems Mikael Lindvall, Dharma Ganesan Software Architecture and Embedded Systems division Fraunhofer Center for Experimental Software Engineering Maryland (FC-MD) © 2012 Fraunhofer USA, Inc.
- 2. Your Presenters Mikael Lindvall, PhD Dharma Ganesan, PhD • Division director, more than 13 • Research scientist, more than 8 years at FC-MD, co-invented FC- years at FC-MD, co-invented FC- MD’s reverse engineering MD’s reverse engineering and approach, analyzed e.g. NASA’s testing approach, analyzed Space Network (10 MLOC ADA, NASA’s Core Flight Software, C++ etc). Review board member GMSEC, Climate Modeling for SN replacement system System etc. etc. (SGSS). © 2012 Fraunhofer USA, Inc.
- 3. Fraunhofer Center – Maryland (FC-MD) • Applied Research and Tech Transfer, non-profit – US incorporated • Affiliated with – University of Maryland, College Park – Fraunhofer Germany • Close to ties to NASA – Goddard Space Flight Center around the corner • Focus on Software Engineering – Especially Software Quality • Business model: Applied research services © 2012 Fraunhofer USA, Inc.
- 4. Fraunhofer Center – Maryland (FC-MD) at MSquare © 2012 Fraunhofer USA, Inc.
- 5. Clients ask Fraunhofer to determine • If their sw architecture/design rules are met • The risk involved if they change the software • If their software meet certain regulations • If their software has defects • If their software is efficient • Etc. etc. Today: How reverse engineering can be used to deal with legacy systems using different kinds of examples on different systems © 2012 Fraunhofer USA, Inc.
- 6. Reverse Engineering at Fraunhofer • Developed an approach to analyze, visualize and describe legacy software – Structure and behavior – Methods and tools – Support from NASA IV&V • Analyzed legacy software systems e.g. – NASA’s Space Network (Ground segment) – NASA’s Core Flight Software – NASA’s GMSEC • More than 10 years © 2012 Fraunhofer USA, Inc.
- 7. Background: Software architecture • Software architecture (SA) deals with components, connectors, and protocols • SA is a multi-dimensional artifact – Each dimension corresponds to one concern (e.g. Database interaction concern) • SA is represented by a collection of views – Development/Implementation view – Runtime view 7 © 2012 Fraunhofer USA, Inc.
- 8. Our Model of SA and RE • Development views – Components of a development view • Directories/files/functions/database tables – Connectors of a development view • Function calls, includes, variable accesses, etc. • Runtime views – Components of a runtime view • Tasks, Processes – Connectors of a runtime view • Sockets, Queues, Shared Memory, Software Bus etc. • Create views from source code to answer questions! 8 © 2012 Fraunhofer USA, Inc.
- 9. The Fraunhofer RE Method • Software architecture is influenced and inspired by external entities (EE) – Programming language libraries – COTS and Frameworks • Reverse Engineering is driven by EE • A knowledge base of EE based on ~24 real-world systems – Several NASA systems and other companies 9 © 2012 Fraunhofer USA, Inc.
- 10. SAVE Sample Software Architecture Visualization and Evaluation Tools (Depends on development environment) Tool Type Purpose Understand Commercial Extracts code-level dependencies and metrics from source code RPA Research Queries the dependency models using relational algebra Prefuse Research Visualizes the content of the knowledge base Similarity Research Determines similarity among files FindBugs Open Source Detects defects in Java code. Other tools used to detect defects in other languages SAVE Research Imports and visualizes dependency models tagged by similarity, metrics, defects, knowledge. Detects architecture violations (compares actual to planned). © 2012 Fraunhofer USA, Inc.
- 11. Example: Common Ground System (CGS) • Ground System implemented in C/C++ • Developed by Johns Hopkins University/ Applied Physics Laboratory (JHU/APL) • 10 years old • Product line for three different NASA missions • Works well • Software Quality is very important © 2012 Fraunhofer USA, Inc.
- 12. Exploring actual architecture © 2012 Fraunhofer USA, Inc.
- 13. The Common Ground System Assessment CSCI Telemetry Data Flow Diagram Web Data Server Requested MOPs/ I&T Points File Users Level 0 Data Files eng_dump Ancillary Products Decommutated 1:N Points File Plots Archived ArchiveServer Telemetry instant_ replay Directives Plotter Directives Telemetry ArchiveServer gap_reporter level_zero Directives instant_replay Archived Telemetry *Timekeeping Sorted System Telemetry merger Telemetry Pkt indexer spooler Files & Pkt Files Indexes Archived Telemetry archive_server Non-Real- Archive of TIme Pkt Pkts and Files Real-Time Indexes Telemetry Packets Archived Telemetry ArchiveServer ArchiveServer Archived Directives Directives Telemetry Non-Real-Time Extracted SSC POC Planning & Telemetry Packets Clients Scheduling 1:N CSCI Telemetry CSCI *Timekeeping System expanded separately LHerrera 08/03 Manually drawn diagram from system documentation © 2012 Fraunhofer USA, Inc.
- 14. A Typical application: eng_dump Automatically drawn diagram based on source code © 2012 Fraunhofer USA, Inc.
- 15. eng_dump’s use of Common App_Specific Automatically drawn diagram based on source code © 2012 Fraunhofer USA, Inc.
- 16. Detecting high level violations © 2012 Fraunhofer USA, Inc.
- 17. The Common Ground System Assessment CSCI Telemetry Data Flow Diagram Web Data Server Requested MOPs/ I&T Points File Users Level 0 Data Files eng_dump Ancillary Products Decommutated 1:N Points File Plots Archived ArchiveServer Telemetry instant_ replay Directives Plotter Directives Telemetry ArchiveServer gap_reporter level_zero Directives instant_replay Archived Telemetry *Timekeeping Sorted System Telemetry merger Telemetry Pkt indexer spooler Files & Pkt Files Indexes Archived Telemetry archive_server Non-Real- Archive of TIme Pkt Pkts and Files Real-Time Indexes Telemetry Packets Archived Telemetry ArchiveServer ArchiveServer Archived Directives Directives Telemetry Non-Real-Time Extracted SSC POC Planning & Telemetry Packets Clients Scheduling 1:N CSCI Telemetry CSCI Common *Timekeeping System expanded separately LHerrera 08/03 © 2012 Fraunhofer USA, Inc.
- 18. Violations of architecture: Common depends on eng_dump AS ED Automatically drawn diagram (actual) based on source code © 2012 Fraunhofer USA, Inc.
- 19. Checking Design Rules © 2012 Fraunhofer USA, Inc.
- 20. Planned Architecture: eng_dump Client Application-Specific Modules Encapsulation of client/server interface Encapsulation of socket communications The socket Manually drawn diagram based on design rule © 2012 Fraunhofer USA, Inc.
- 21. The Actual Architecture: eng_dump (“components” collapsed) Automatically drawn diagram based on source code © 2012 Fraunhofer USA, Inc.
- 22. Mapping planned and actual using patterns © 2012 Fraunhofer USA, Inc.
- 23. The Actual Architecture vs. The Planned: eng_dump Client Dependency in planned, Dependency in not in actual actual, not in planned Who does socket communicate with? © 2012 Fraunhofer USA, Inc.
- 24. Adding Components and Layers to Common © 2012 Fraunhofer USA, Inc.
- 25. Common; across all applications Automatically drawn diagram based on source code © 2012 Fraunhofer USA, Inc.
- 26. Suggested Target Architecture for Common Basic rule: A lower layer cannot access a higher layer Manually drawn diagram © 2012 Fraunhofer USA, Inc.
- 27. Components and Layers Manual refactoring of files into components and layers © 2012 Fraunhofer USA, Inc.
- 28. Layers with dependencies Let’s see how this target structure maps to the actual implementation Automatically drawn diagram, manual layout © 2012 Fraunhofer USA, Inc.
- 29. Back links from lower layer to higher layer Automatically drawn diagram, manual layout © 2012 Fraunhofer USA, Inc.
- 30. Analyzing embedded software © 2012 Fraunhofer USA, Inc.
- 31. Case Study: CARA Medical Device Blood Pressure Monitor CARA Software 31 © 2012 Fraunhofer USA, Inc.
- 32. Sample analysis needs at FDA • What is the architecture of the software in general? – Is the software putrid? • Where is a certain “Safety Function” located? – Is it present at all? • Once located: – What is the quality of that “Safety Function”? • From various perspective (cloning, look and feel etc.) – Does the architecture allow for “modularized verification” of the “Safety Function”? – If not, can the architecture be refactored to facilitate verification using detailed but time-consuming static analysis tools? 32 © 2012 Fraunhofer USA, Inc.
- 33. Analysis Types • Goal: Analysis of Architectural Quality • Variability Management – OS/Hardware Abstraction • Reverse architecture of module dependencies • Reverse architecture of task dependencies • Analysis of Testability 33 © 2012 Fraunhofer USA, Inc.
- 34. Summary Generator Output CARA has • Several keywords of Windows libraries (e.g. windows.h) • Several keywords of VxWorks libraries (e.g. vxworks.h) • Multitasks because it has the taskSpawn keyword • Inter-Process because it has msgQSend/Receive keywords • Semaphores because it has semBCreate and semTake keywords • GUI because it has keywords of GUI libraries (e.g. afxwin.h) 34 © 2012 Fraunhofer USA, Inc.
- 35. Views of SAVE Light 35 © 2012 Fraunhofer USA, Inc.
- 36. Analysis of OS Variability • Fraunhofer has a knowledge base (KB) of OS functions/files for different OS types • KB was used for CARA analysis • Automatically identified OS types of CARA: – Vxworks – Simulation of Vxworks APIs using Windows APIs 36 © 2012 Fraunhofer USA, Inc.
- 37. Analysis of OS Variability #ifdef WIN32 sim.cpp #include vxworsksim.h src/AD_Reader.c #endif src/BP_Reader.c src/CARA_CUII.c src/CARA_Calculations.c src/CARA_DA.c src/CARA_Globals.c src/CARA_Globals.h src/CARA_Interface.c CARA Architecture lacks an OS abstraction src/CARA_Macroes.c src/CARA_Main.c OS concerns present in several files src/CARA_Timer.c src/CARA_Types.h src/COM_Reader.cpp src/VxWorksSim.h src/dscud.h 37 © 2012 Fraunhofer USA, Inc.
- 38. Analysis of OS Variability File Name Count of #if WIN32 src/Interface.c 40 src/Cara_Main.c 6 src/Cara_DA.c 5 • Unnecessary complexity to manage OS variants • 40 #if could have been avoided if the architecture has an OSAL 38 © 2012 Fraunhofer USA, Inc.
- 39. OSAL in NASA CFS … … … … … • One generic interface for different OS types • Implementations for each OS type • At build time developers can use the OS of interest 39 © 2012 Fraunhofer USA, Inc.
- 40. Summary of OS Variability • CARA lacks an OSAL – Complexity to support Windows and Vxworks • OS variability analysis helped the FDA to run CodeSonar (static analysis tool) on CARA • Identification of the right compiler switch to overcome the missing Vxworks related files 40 © 2012 Fraunhofer USA, Inc.
- 41. Analysis of Hardware Abstraction Because the CARA system was targeted for a specific embedded system platform, test execution was not possible on the development machines. A test platform was prepared with facilities to simulate sensor inputs and monitor system responses. Initial difficulties setting up the test hardware postponed the start of testing for a number of months. Once these problems were addressed, there remained a limited amount of time available to test the increment. Snippet from CARA documentation 41 © 2012 Fraunhofer USA, Inc.
- 42. Analysis of Hardware Abstraction double CARA_READ_EMF(void) { #ifndef TEST /* Read the EMF value from the A/D board. */ float Actual_Value; Actual_Value = AD(EMF_CHANNEL); Actual_Value = (float)(Actual_Value * (-1.0)); dprintf("EMF %fn", Actual_Value); return (double) Actual_Value; #else return CARA_EMF_VALUE; #endif } Lack of hardware abstraction layer (HAL) Testing could have been facilitated better with HAL (e.g. Stubs) 42 © 2012 Fraunhofer USA, Inc.
- 43. Extraction of Runtime Views • Pool of relations are semi-automatically extracted using our KB and regular expressions • Extracted relations are stored in a relational database (text file) • Relational algebraic operators (e.g., Union, Transitive Closure) are used to extract runtime views 43 © 2012 Fraunhofer USA, Inc.
- 44. Task creation view <<optional>> <<optional>> <<optional>> BP_Reader AD_Reader COM_Reader CARA_Main CARA_KVO_SERVICE CARA_B2B_Broker CARA_CUII_Svc CARA_Log_Svc CARA_Display_Svc CARA_Warn_Svc CARA_Alarm_Svc Task Creation of Task 44 © 2012 Fraunhofer USA, Inc.
- 45. Task-Queue-Task View <<optional>> BP_Reader Read from msg queue Write to msg queue Task CARA_B2B_Broker BP_Reader_Q_ID CARA_CUII_Svc CUII_MSGQ_ID CARA_MSGQ_ID CARA_Main CARA_LOGQ_ID CARA_Log_Svc CARA_DSPQ_ID CARA_Display_Svc <<optional>> <<optional>> 45 CARA_Warn_Svc AD_Reader COM_Reader CARA_KVO_SERVICE CARA_Alarm_Svc © 2012 Fraunhofer USA, Inc.
- 46. Task-Queue-Task View • Useful to reason about overall complexity • Useful to reason about testability of each task – Can tasks be unit tested independently? • Tasks also communicate using shared variables (see demo) 46 © 2012 Fraunhofer USA, Inc.
- 47. Identifying high risk sw modules by combining information Structures Defects Clones © 2012 Fraunhofer USA, Inc.
- 48. High Level Architecture • The high level architecture seems fairly organized and clean, there are however worries on the left © 2007 Fraunhofer 48 CESE © 2012 Fraunhofer USA, Inc.
- 49. High Priority Bugs 1 118 52 19 2 14 2 23 9 1 29 9 • Number of high priority bugs for each high level component – mocclient is the most buggy package with 118 bugs – dsdm, shareclient, and oamclient also contain many highly severe bugs © 2007 Fraunhofer 49 CESE © 2012 Fraunhofer USA, Inc.
- 50. Duplicates Cloned bugs 3 3 89 3 3 • Number of duplicates shared among high level components (duplicate dependencies) – mocclient and oamclient share most duplicates – snif shares duplicates with many other components – Same high priority FindBugs bug in several cloned files © 2007 Fraunhofer 50 CESE © 2012 Fraunhofer USA, Inc.
- 51. Conclusion • Overview of reverse engineering • Knowledge based reverse engineering is a simple, yet promising idea • Architectural analysis offers complementary views on FDA’s static analysis – Helps to configure static analysis – Helps to plan static analysis on small portions • Detected issues of CARA – Lack of OS abstraction layer – Lack of hardware abstraction layer – File structure and task structure are not symmetric 51 © 2012 Fraunhofer USA, Inc.
- 52. Summary • Architecture can be reverse engineered using external dependencies • Multiple views are required to reason about software quality • Specified architecture can be compared with the actual architecture • Fraunhofer has wealth of experience in: Product Line, Architecture, and Reverse Engineering © 2012 Fraunhofer USA, Inc.
- 53. Sample Publications • Developing an Approach for Analyzing and Verifying System Communication, The Aerospace conference, 2009 • Verifying Architectural Design Rules of the Flight Software Product Line, The Software Product Line Conference (SPLC), 2009 • Connecting Research and Practice: An Experience Report on Research Infusion with SAVE, Innovations in Systems and Software Engineering a NASA Journal, 2010 • D. Ganesan. Software Architecture Discovery for Testability, Performance, and Maintainability of Industrial Systems. PhD Thesis, Vrije Universiteit Amsterdam, 2012 (http://dare.ubvu.vu.nl/handle/1871/32693) © 2012 Fraunhofer USA, Inc.
- 54. Contact information • www.fc-md.umd.edu • Mikael Lindvall – 240-487-2902 – mlindvall@fc-md.umd.edu • Dharma Ganesan – 240-487-2915 – dganesan@fc-md.umd.edu © 2012 Fraunhofer USA, Inc.