architecture extraction from code
DESCRIPTION
TRANSCRIPT
Architecture Extraction from code
Course Seminar
By
Sanyam Goyal (06005008)
Guide : Prof. R.K. Joshi
1
Outline
Motivation
Different Techniques
◦ Clustered based
FOCUS
ROMANTIC
◦ Pattern based Conclusion
Conclusion
References
2
Motivation
Old software systems are often not
documented or very less documentation
is available, even in the systems where
documentation is available there is no
explicit mention of the architecture that
the code possesses.
New changes to the system need a
knowledge of implicit architecture that
the system possess.
3
Motivation
Legacy Transformation
It is a tough task to convert a 10,000 line
Cobol code to C/C++ code if the
programmer is unaware of the underlying
architecture .
4
Motivation
System evolution
As system evolves , it tends to drift from
it’s original architecture .
So it is very important to recover or
reconstruct the architecture of the
system in the spirit that new changes to
the system do not affect the existing
working model.
5
Different Techniques
Approaches to architecture extraction can be classified mainly into clustered based techniques and pattern-based techniques.
The clustered-based techniques gradually build the architecture by grouping the components .It is a Bottom up process which starts with a low-level knowledge like source code and gradually discover the complete architecture.
Pattern-based techniques on the other hand is a Top-down process which first build a conceptual architecture of the system in terms of some pattern and then the software system is searched to find instances of that pattern in a top-down manner
6
Clustering based Techniques.
The focus of techniques here is to view
different parts of the source code as a
single component (cluster) , then use an
hierarchical approach to find the
architecture .
7
Clustering based Techniques.
Cluster
Cluster
Architecture
8
Clustering based Techniques.
FOCUS
ROMANTIC
9
FOCUS
In software evolution , architecture erosion is a common problem where architecture is modified to a point such that the basic properties of the architecture no longer hold.
FOCUS is an approach to recover architecture in such applications.
It allows engineers to focus their attention directly to the part that has affected mainly from the change and recover the architecture in an incremental fashion.
10
FOCUS
11
FOCUS
Architecture Recovery
System Evolution
12
Architecture Recovery
13
Architecture recovery
1. Indentifying components.• Use call-graphs, class-diagram
• Inheritance ,Aggregation
2. Propose idealized architectural model• basis of the future evolution’s requirements
• may incorrectly characterize some of the application aspects
3. Map identified components to different architectural elements• intermediate architecture, which contains those components
which fits with the idealized architecture.
4. Identify key use-cases • UML use-cases to express the application requirements
• Three categories of the use-cases .
• First is the category of cases which is unaffected by the desired modification,
• Second are those corresponding to the new changes
• Third are the earlier existing cases which now needs to be modified according to the changes
14
Architecture recovery
5. Analyze Component interaction
• Along with the static relationship of classes their interactions and
control flow must also be analyzed
• UML sequence diagram
6. Generate refined Architecture
• The control flow identified in the previous step can be used to find
remaining components mapping from the architectural elements
and their inter-relations with earlier discovered components.
• At the same time this can be used to find out inconsistencies
(missing component interactions) which were introduced by the
step 2.
15
System evolution
16
System evolution
1. Propose idealized architecture Evolution plan• high-level architecture evolution plan like distributed client server
model
2. Add/Modify components • identify which components needs modification and what new
components need to be added.
3. Update components interactions • modify the existing component interactions also. Adding a new feature
may cause the earlier component interactions to change
4. Generate Evolved Architecture• changes made in the previous steps now needs to be integrated with
original architecture that was recovered.
• This generated architecture serves as the basis for all the design issue related to the new modifications to the system
5. Set the new Focus• the components which were affected by the previous iteration now
become new focus, so that they can be more refined.
17
FOCUS
Figure4. Architecture Obtain in first iteration of Recovery of
Drawcli Application 18
FOCUS
In summary this is an approach to recover and evolve architecture of moderately sized OO applications.
The approach reduces the complexity involved in the recovery process by allowing engineers to focus on a particular segment of the architecture.
The idea is that the recovery is not just one-time process. You need to maintain the architecture as the system evolves
19
ROMANTIC
The main idea behind this approach is to use
system structural and semantic properties to
come up with a quasi-automatic process of
extracting architecture from OO Systems
semantic information about the system like
architecture patterns, architectural quality is
used to decrease the need for human-
interaction
The approach is based on the two principals
20
Principle 1 - Extraction of architecture from
object-oriented systems
21
Principle 1 - Extraction of architecture from
object-oriented systems
define the mapping between the object concepts and the architectural elements.
extract the architecture in terms of classes, shapes, components and connectors
shapes as collection of components where each component is composed of several classes which may belong to different packages.
Each shape is portioned in two parts namely 1)shape interface 2) center .
“shape interface” contains all the classes(components) which have links to the outside of shape like a class may call a function that is defined in a different class(component) . The remaining classes of shape are referred to as “center”.
22
Principle 2 -guides of the architecture
extraction process
23
Principle 2 -guides of the architecture
extraction process
Architecture is considered relevant if it satisfies these four guides.
Firstly it must be semantically correct, meaning that it must not convey any meaningless information .
Secondly architectural quality must be good
Thirdly it should respect the recommendation specified by the architect and the constraint and specification specified in system documentation as far as possible .
lastly it must be adaptable to the specificity of the deployment hardware architecture.
24
How to evaluate software architecture
semantics
semantic sub-characteristics defined are
composability, autonomy and specificity.
refine these sub-characteristics into
component properties like cohesion,
coupling. We link these properties to the
shape properties.
shape properties are measured mainly by
two parameters , Firstly Cohesion ,
Secondly Coupling
25
How to evaluate software architecture
semantics
Semantic measurement function based on our three sub-characteristics, autonomy, composability and specificity). say Spe ,C, Auto respectively
Where Ai is designed by the engineers .This function is used in a hierarchical clustering algorithm to obtain a shape (partition of classes) and consequently a semantically correct architecture
26
How to evaluate software architecture
semantics
27
Romantic
In summary This approach is based on the
component semantic characteristics.
These characteristics helps in creating a
partioning the system classes and
extracting components from it
28
Pattern based techniques
29
Pattern based techniques
Top-down approach.
Uses interaction with human extensively to put mental model of architecture as well as to verify the results of recovery.
Two phases◦ Offline phase Call-graphs, class-diagrams, dependency graphs
◦ Online User provides architectural patterns to in the form of a
query
A* search algorithm to match different sub-graphs that satisfy the pattern given by user.
30
System Representation
system software is represented in terms of a entity-relationship source graph Gs = (Ns
,Rs) .
Nodes of the graph ( ni )represents system entities like data-types , files , classes ,variables ,functions ,interfaces etc.
edges( ej ) represent the interaction between various system entities ,like calling a function from a class ,inheritance etc .
graph is decomposed into sub-graphs where each sub-graph works as a separate search space
31
Pattern representation
The abstract patterns are represented in a query language (AQL) .
An AQL query can be represented as a graph which consists of composite nodes and links.
A node is a expanded into a pattern region Gi
pr, and each link is expanded into a group of edges Ri
m<->pr .
In the ith matching phase a pattern region is matched with source graph Gg(i)
sr and the edges Ri
m<->pr are matched with corresponding connectors edges Ri
m<->sr
32
Pattern representation
Sample AQL Query
BEGIN-AQLSUBSYSTEM S1
MAIN-SEEDS files server.c client.c
IMPORTS: rsrc ?IR
RESOURCES
Rsrc ?R1(2…4) S2
EXPORTS
RESOURCES: rsrc ?ER
Rsrc ?R3(2…10) S2
CONTAINS FILES : file $CFI(3…13) Files client.c server.c
RELOCATES: NO files file1.php TO S4
END-AQL
33
graph matching
matches the query graph (pattern-graph)
Gip with the input graph Gi
I
k(no of different AQL queries) different
phases .
The results obtained in each phase should
satisfy the constraint specified by the AQL
query
34
graph matching
A* search algorithm.
Algorithm generates a search tree which represents the recovery of module Mi (corresponding to ith AQL query). This graph contains a root node which is the matching of main-seed ni in source graph and the first place-holder (node) ni , in Gi
pr.
Different non-leafs nodes at one level of the search graph represents the alternative matching of the placeholder from the source graph and the leaf nodes which represents the solution obtained from the marching process.
It follows A*, so at each step the cost of matching the source node and corresponding pattern region is evaluated and the node with least cost is expanded.
The difference from normal A* is that depth of each search tree is bounded by numbers of placeholders –nodes in the particular pattern region or number of modules in the AQL query.
35
CONCLUSION
Legacy systems, architectural erosion and need for modularity are few features that engineers require.
The report compares different approaches to recover the software architecture. The comparison was based on different inputs that it takes user in- cooperation, knowledge of previous architecture and documentation available.
The common characteristic in all these approaches is that they all recover the architecture in an incremental way.
Both clustered-based techniques as well as the pattern-based techniques have proven to be efficient in recovering architecture.
36
References/Readings
Lei Ding; Medvidovic, N., "Focus: a light-weight, incremental approach to software architecture recovery and evolution," Software Architecture, 2001. Proceedings. Working IEEE/IFIP Conference on , vol., no., pp.191-200,
Sartipi, K.; Kontogiannis, K., "A graph pattern matching approach to software architecture recovery ," Software Maintenance, 2001. Proceedings. IEEE International Conference on , vol., no., pp.408-419, 2001
Chardigny, S.; Seriai, A.; Oussalah, M.; Tamzalit, D., "Extraction of Component-Based Architecture from Object-Oriented Systems," Software Architecture, 2008. WICSA 2008. Seventh Working IEEE/IFIP Conference on , vol., no., pp.285-288, 18-21 Feb. 2008
D Pollet, S Ducasse, L Poyet, I Alloui, S Cimpan, … - … European Conference on Software Maintenance and Reengineering -people.untyped.org
http://www.sparxsystems.com.au/uml-tutorial.html
Czeranski, J.; Eisenbarth, T.; Kienle, H.; Koschke, R.; Simon, D., "Analyzing xfig using the Bauhaus tool," Reverse Engineering, 2000. Proceedings. Seventh Working Conference on , vol., no., pp.197-199, 2000
37
References/Readings
Eixelsberger, W.; Ogris, M.; Gall, H.; Bellay, B., "Software architecture
recovery of a program family," Software Engineering, 1998.
Proceedings of the 1998 International Conference on , vol., no., pp.508-
511, 19-25 Apr 1998
J. M. Bieman and B.-K. Kang Cohesion and reuse in an object-
oriented system. In Proc. of the Symp. on Software reusability,SSR ’95,
pages 259–262, 1995.
R. Agrawal and R. Srikant. Fast algorithms for mining association
rules. In Proceedings of the 20th International Conference on Very Large
Databases, pages 487–499, 1994
ISO/IEC-9126-1. In Software engineering - Product quality - Part 1:
Quality Model. ISO-IEC, 2001.
C. Szyperski. Component Software. ISBN: 0-201-17888-5. Addison-
Wesley, 1998
38
Thanks!
39