This document discusses reverse architecting software by extracting relationships from source code using relation algebra. It describes extracting relations from code without compiling or linking, storing them in a database, and applying relation algebra operations like join and inverse to abstract the relations. The abstracted relations can then be visualized as graphs or tables to understand aspects of the software architecture like inter-task communication and message queue usage. Reverse architecting is challenging but relation algebra can help reformulate many analysis questions and filter irrelevant data to meet analysis goals.

1. Dharma Ganesan
Reverse Architecting using
Relation Algebra

2. 2
What’s On The Agenda
● Software Architecture
● Reverse Architecting
● A little bit math - I promise
● Extract-Abstract-Present to Reverse Architecting
● Demos (during the presentation)
● Some References

3. 3
Software Architecture
● Software architecture deals with the design of the
high-level structure of the software
● Assembly of architectural elements in some well-chosen
forms to satisfy requirements
● (including Reliability, Scalability, Portability, etc)
● Software architecture deals with
● abstraction
● decomposition and composition
● styles (pipe-and-filter, publish-subscribe, etc.)

4. 4
Describing Software Architecture
using Views
● How to best describe Software Architecture
is a topic of on-going R&D
● In literature, views are used to describe
Software Architecture
● Each view address one concern, for example:
● Structural view shows the decomposition of
system
● Behavioral view shows how components
interact at run-time
● Deployment view shows how components
are assigned to hardware elements

5. 5
Reverse Architecting
Informally, extracting architecture information from
source code (including makefiles, docs, test cases,
etc.)
Some challenges:
● Software architecture is an invisible one
● It is difficult to “see” architecture in source code
● Real-world systems have a lot of code
Goal of reverse architecting: Semi-automatically
extract architecture from source code

6. 6
Some questions we ask
● What are the entry-points to the system?
● Which classes inherit from this class?
● Which files deal with network communication?
● Is this function reachable from ‘main’?
● Are there missing code not in repo?
● Which functions are dead?
● etc. etc. etc.
All these questions can be be viewed as relational
algebra questions!

7. 7
Just a bit of math (I promise)
What do we mean by Relation Algebra?
Three things:
Set - an unordered collection
E.g., set of files {f1.c, f2.c, …}
Binary Relation - an unordered set of pairs
E.g., {<main, run>, <run, execute>, …, }
Multi-Relation - Weighted Binary Relation
E.g., {<caller, callee, 5>, …}

8. 8
Relation Algebra Queries
They are made of set-theory operators only
For example, union, intersection, complement, etc.
Compose two relations using join (a.k.a., comp)
part_of= {<a A}, <b B>, <c C>}
call = {<a b>, <b, c>}
E.g: inverse(part_of) comp (call) comp (part_of)?

9. 9
Relation Algebra Toolset
Made of small utilities for each set-theory operator
Combine utilities using pipe-and-filter style
rel_inv part_of | rel_comp call - | rel_comp -
part_of
I personally used RA tools for several reverse
architecting projects
My Phd thesis has more details

10. 10 A Reverse Architecting
Approach (Philips in 1990s)
Extraction: semi-automated extraction of different
relations (import, inherit, call, etc.)
Abstraction: rise the level of abstraction using
relational algebra queries (imagine SQL)
Presentation: visualize using graphs, tables, etc.
(These were published
by Philips)

11. 11
Extraction
● Language-specific parsers to extract different
relations: inherit, call, include, etc.
○ Code need not compile or link
● Each relation is stored in database/files
● Depending on the goal, more custom parsers
have to be developed to extract code relations
● For example, if your goal is to extract inter-task
RPC views, you need to
○ extract tasks, queue names, which function
writes to or read from queues, etc.

12. 12
Abstraction
A suite of relation algebra operators was developed
for abstraction (see demos)
Again, depending on the goal one could apply
different abstraction operators
Some common abstraction (examples):
● Lift class-level dependencies to package-level
● Filter out irrelevant information for your goal
○ For example, show all Java packages that
depend on Crypto packages
● Abstraction of runtime structure to show
inter-task communication (more details later)

13. 13
Some examples: Folder-level
dependency from code relations

14. 14
A medical device case study
Goal: Extract architecture from source code
Visualize inter-task and msg queue communication
Approach:
Extract relations from code
Abstraction using Relation Algebra
Visualize using our graph visualization tools

15. 15
Extracted relations/sets
Our parser extracts names of tasks, queues,
semaphores, etc by pattern matching of library calls

16. 16
Abstraction
We write SQL-like queries using join, inverse, and
other operations on the extracted relations
Output is also relations/sets

17. 17
Presentation
We visualize relations as graphs or tables in general
For inter-task structure, we have something like this
from abstracted relations:

18. 18
Conclusion/Takeaways
● Reverse architecting is a challenging problem
● Extract-Abstract-Present using relational algebra
can help with reverse architecting
● Many of the analysis questions can be
reformulated as relational algebra questions!
● The key is to have a goal for your reverse
architecting effort - to filter out irrelevant data

19. 19 Some Reverse Engineering
Papers (not complete at all)
https://www.win.tue.nl/~wstomv/edu/2ii45/yea
r-0910/Maintaining_a_Legacy.pdf
https://www.cs.cmu.edu/~aldrich/courses/654-s
p05/ReengineeringTaxonomy.pdf
https://ieeexplore.ieee.org/document/5959691
https://ieeexplore.ieee.org/document/5071104
…