Architecture Extraction From Code


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Architecture Extraction From Code

  1. 1. Architecture Extraction from code Course Seminar By Sanyam Goyal (06005008) Guide : Prof. R.K. Joshi 1
  2. 2. Outline  Motivation  Different Techniques ◦ Clustered based  FOCUS  ROMANTIC ◦ Pattern based Conclusion  Conclusion  References 2
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. Clustering based Techniques. Cluster Architecture Cluster 8
  9. 9. Clustering based Techniques.  FOCUS  ROMANTIC 9
  10. 10. 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
  11. 11. FOCUS 11
  12. 12. FOCUS  Architecture Recovery  System Evolution 12
  13. 13. Architecture Recovery 13
  14. 14. 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
  15. 15. 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
  16. 16. System evolution 16
  17. 17. 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
  18. 18. FOCUS Figure4. Architecture Obtain in first iteration of Recovery of Drawcli Application 18
  19. 19. 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
  20. 20. 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
  21. 21. Principle 1 - Extraction of architecture from object-oriented systems 21
  22. 22. 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
  23. 23. Principle 2 -guides of the architecture extraction process 23
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. How to evaluate software architecture semantics 27
  28. 28. 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
  29. 29. Pattern based techniques 29
  30. 30. 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
  31. 31. 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
  32. 32. 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 Gipr, 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
  33. 33. Pattern representation Sample AQL Query BEGIN-AQL SUBSYSTEM 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
  34. 34. graph matching  matches the query graph (pattern-graph) Gip with the input graph GiI  k(no of different AQL queries) different phases .  The results obtained in each phase should satisfy the constraint specified by the AQL query 34
  35. 35. 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 Gipr.  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
  36. 36. 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
  37. 37. 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 -   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
  38. 38. 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
  39. 39. Thanks! 39