Reverse Engineering of Software Architecture

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.

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).

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


Fraunhofer Center – Maryland (FC-MD)
at MSquare


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


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


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

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

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

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).


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


Exploring actual architecture


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

A Typical application: eng_dump

Automatically drawn diagram based on source code

eng_dump’s use of Common
App_Specific


Detecting high level violations


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


Violations of architecture:
Common depends on eng_dump

AS
ED

Automatically drawn diagram (actual) based on source code

Checking Design Rules


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

The Actual Architecture: eng_dump (“components” collapsed)


Mapping planned and actual using
patterns


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?


Adding Components and Layers
to Common


Common; across all applications


Suggested Target Architecture for Common

Basic rule: A lower layer cannot access a higher layer

Manually drawn diagram

Components and Layers

Manual refactoring of files into components and layers

Layers with dependencies

Let’s see how this target structure maps to the
actual implementation

Automatically drawn diagram, manual layout

Back links from lower layer to higher layer

Automatically drawn diagram, manual layout

Analyzing embedded software


Case Study: CARA Medical Device

Blood Pressure
Monitor

CARA Software

31

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

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

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

Views of SAVE Light

35

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

#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

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

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

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

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

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

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

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

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

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

Identifying high risk sw modules by
combining information

Structures
Defects
Clones


High Level Architecture

• The high level architecture seems fairly
organized and clean, there are however worries
on the left
© 2007 Fraunhofer 48
CESE

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
CESE

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
CESE

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

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


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)


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

Reverse Engineering of Software Architecture

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Reverse Engineering of Software Architecture

Semelhante a Reverse Engineering of Software Architecture (20)

Mais de Dharmalingam Ganesan

Mais de Dharmalingam Ganesan (20)

Último

Último (20)

Reverse Engineering of Software Architecture