Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software Architecture Reconstruction: Why What and How

1,607 views

Published on

Every system is a legacy system, the moment a programmer writes a line of code it becomes a legacy. Therefore in even relatively new systems similar to long lived systems, developers are faced with a body of code that they need to understand, and from which they need to extract architectural knowledge. Unfortunately, anecdotal evidence has shown that such knowledge tends to be tacit in nature, stored in the heads of people, and inconsistently scattered across various software artifacts and repositories. Furthermore, architectural knowledge vaporizes over time. Given the size, complexity, and longevity of many projects, developers therefore often lack a comprehensive knowledge of architectural design decisions and consequently make changes in the code that inadvertently degrade the underlying design and compromise its qualities.

This technical briefing will answer three fundamental questions about software architecture recovery: Why? What? and How? Through several examples it articulates and synthesizes technical forces and financial motivations that make software companies to invest in software architecture recovery. It discusses “what” are the pieces of design knowledge that can be recovered and lastly demonstrates a methodology as well as required tools for answering “how” to reconstruct architecture from implementation artifacts.

Published in: Software
  • Be the first to comment

Software Architecture Reconstruction: Why What and How

  1. 1. Software Archeology Mehdi Mirakhorli Rochester Institute of Technology mehdi@se.rit.edu Winter 2015 Software Architecture Reconstruction: Why? What? and How? 1
  2. 2. What do I do for the living? 2
  3. 3. Map of My Research 3 Software Architecture Requirements Engineering Cyber security/Physical Software Architecture
  4. 4. Map of My Research 4 Software Architecture Software Architecture
  5. 5. WORKING DEFINITIONS 5
  6. 6. 6 Master Slave HB Detailed Example: An architectural view 6 Apache Hadoop Architecture
  7. 7. 6 Master Slave HB Detailed Example: An architectural view 7 Apache Hadoop Architecture Requirements# 1: highly available system, where hardware failure can be the norm rather than the exception
  8. 8. 6 Master Slave HB Detailed Example: An architectural view 8 Apache Hadoop Architecture Requirements# 1: highly available system, where hardware failure can be the norm rather than the exception
  9. 9. 6 Master Slave HB Decision # 1: Use Master-slave Architectural Style where slave processes are replicated Detailed Example: An architectural view 9 Apache Hadoop Architecture Requirements# 1: highly available system, where hardware failure can be the norm rather than the exception
  10. 10. 6 Master Slave HB Decision # 1: Use Master-slave Architectural Style where slave processes are replicated Detailed Example: An architectural view 10 Decision # 2: Checkpoint updated data, and bundle replicas (send every 2 seconds) – in order to meet performance goals. Apache Hadoop Architecture Requirements# 1: highly available system, where hardware failure can be the norm rather than the exception
  11. 11. 6 Master Slave HB Decision # 1: Use Master-slave Architectural Style where slave processes are replicated Detailed Example: An architectural view 11 Decision # 2: Checkpoint updated data, and bundle replicas (send every 2 seconds) – in order to meet performance goals. Decision # 3: Use heartbeat tactic to monitor availability of task trackers and data nodes. Heartbeat must beat every .25 seconds to balance availability and performance. Apache Hadoop Architecture Requirements# 1: highly available system, where hardware failure can be the norm rather than the exception
  12. 12. 6 Master Slave HB Decision # 1: Use Master-slave Architectural Style where slave processes are replicated Detailed Example: An architectural view 12 Decision # 2: Checkpoint updated data, and bundle replicas (send every 2 seconds) – in order to meet performance goals. Decision # 3: Use heartbeat tactic to monitor availability of task trackers and data nodes. Heartbeat must beat every .25 seconds to balance availability and performance. Decision # 4: Use proxy handles failure pattern to shield clients from failures, and to support fault tolerance (i.e. service continues in the face of transient failure. Apache Hadoop Architecture Requirements# 1: highly available system, where hardware failure can be the norm rather than the exception
  13. 13. 6 Master Slave HB Decision # 1: Use Master-slave Architectural Style where slave processes are replicated Detailed Example: An architectural view 13 Decision # 2: Checkpoint updated data, and bundle replicas (send every 2 seconds) – in order to meet performance goals. Decision # 3: Use heartbeat tactic to monitor availability of task trackers and data nodes. Heartbeat must beat every .25 seconds to balance availability and performance. Decision # 4: Use proxy handles failure pattern to shield clients from failures, and to support fault tolerance (i.e. service continues in the face of transient failure. Apache Hadoop Architecture Requirements# 1: highly available system, where hardware failure can be the norm rather than the exception Requirements# 2: Provide secure services for the client
  14. 14. 6 Master Slave HB Decision # 1: Use Master-slave Architectural Style where slave processes are replicated Detailed Example: An architectural view 14 Decision # 2: Checkpoint updated data, and bundle replicas (send every 2 seconds) – in order to meet performance goals. Decision # 3: Use heartbeat tactic to monitor availability of task trackers and data nodes. Heartbeat must beat every .25 seconds to balance availability and performance. Decision # 4: Use proxy handles failure pattern to shield clients from failures, and to support fault tolerance (i.e. service continues in the face of transient failure. Apache Hadoop Architecture Requirements# 1: highly available system, where hardware failure can be the norm rather than the exception Requirements# 2: Provide secure services for the client
  15. 15. 6 Master Slave HB Decision # 1: Use Master-slave Architectural Style where slave processes are replicated Detailed Example: An architectural view 15 Decision # 2: Checkpoint updated data, and bundle replicas (send every 2 seconds) – in order to meet performance goals. Decision # 3: Use heartbeat tactic to monitor availability of task trackers and data nodes. Heartbeat must beat every .25 seconds to balance availability and performance. Decision # 4: Use proxy handles failure pattern to shield clients from failures, and to support fault tolerance (i.e. service continues in the face of transient failure. Apache Hadoop Architecture Requirements# 1: highly available system, where hardware failure can be the norm rather than the exception Decision # 1: Mutual Authentication with Kerberos RPC (SASL/GSSAPI) on RPC connections Requirements# 2: Provide secure services for the client
  16. 16. 6 Master Slave HB Decision # 1: Use Master-slave Architectural Style where slave processes are replicated Detailed Example: An architectural view 16 Decision # 2: Checkpoint updated data, and bundle replicas (send every 2 seconds) – in order to meet performance goals. Decision # 3: Use heartbeat tactic to monitor availability of task trackers and data nodes. Heartbeat must beat every .25 seconds to balance availability and performance. Decision # 4: Use proxy handles failure pattern to shield clients from failures, and to support fault tolerance (i.e. service continues in the face of transient failure. Apache Hadoop Architecture Requirements# 1: highly available system, where hardware failure can be the norm rather than the exception Decision # 1: Mutual Authentication with Kerberos RPC (SASL/GSSAPI) on RPC connections Decision # 2: Maintain an Audit Trail Requirements# 2: Provide secure services for the client
  17. 17. 6 Master Slave HB Decision # 1: Use Master-slave Architectural Style where slave processes are replicated Detailed Example: An architectural view 17 Decision # 2: Checkpoint updated data, and bundle replicas (send every 2 seconds) – in order to meet performance goals. Decision # 3: Use heartbeat tactic to monitor availability of task trackers and data nodes. Heartbeat must beat every .25 seconds to balance availability and performance. Decision # 4: Use proxy handles failure pattern to shield clients from failures, and to support fault tolerance (i.e. service continues in the face of transient failure. Apache Hadoop Architecture Requirements# 1: highly available system, where hardware failure can be the norm rather than the exception Decision # 1: Mutual Authentication with Kerberos RPC (SASL/GSSAPI) on RPC connections Decision # 2: Maintain an Audit Trail Decision # 3: Data Encryption on RPC Data Encryption on Block data transfer Data Encryption on HTTP Requirements# 2: Provide secure services for the client
  18. 18. 6 Master Slave HB Decision # 1: Use Master-slave Architectural Style where slave processes are replicated Detailed Example: An architectural view 18 Decision # 2: Checkpoint updated data, and bundle replicas (send every 2 seconds) – in order to meet performance goals. Decision # 3: Use heartbeat tactic to monitor availability of task trackers and data nodes. Heartbeat must beat every .25 seconds to balance availability and performance. Decision # 4: Use proxy handles failure pattern to shield clients from failures, and to support fault tolerance (i.e. service continues in the face of transient failure. Apache Hadoop Architecture Requirements# 1: highly available system, where hardware failure can be the norm rather than the exception Decision # 1: Mutual Authentication with Kerberos RPC (SASL/GSSAPI) on RPC connections Decision # 2: Maintain an Audit Trail Decision # 3: Data Encryption on RPC Data Encryption on Block data transfer Data Encryption on HTTP Decision # 4: Secure DataNode: DataNodes must authenticate themselves Requirements# 2: Provide secure services for the client
  19. 19. 6 Master Slave HB Decision # 1: Use Master-slave Architectural Style where slave processes are replicated Detailed Example: An architectural view 19 Decision # 2: Checkpoint updated data, and bundle replicas (send every 2 seconds) – in order to meet performance goals. Decision # 3: Use heartbeat tactic to monitor availability of task trackers and data nodes. Heartbeat must beat every .25 seconds to balance availability and performance. Decision # 4: Use proxy handles failure pattern to shield clients from failures, and to support fault tolerance (i.e. service continues in the face of transient failure. Apache Hadoop Architecture Requirements# 1: highly available system, where hardware failure can be the norm rather than the exception Decision # 1: Mutual Authentication with Kerberos RPC (SASL/GSSAPI) on RPC connections Decision # 2: Maintain an Audit Trail Decision # 3: Data Encryption on RPC Data Encryption on Block data transfer Data Encryption on HTTP Decision # 4: Secure DataNode: DataNodes must authenticate themselves Requirements# 2: Provide secure services for the client More Decisions: A non-trivial architecture is likely to be composed of hundreds, if not thousands of architectural decisions.
  20. 20. 6 Master Slave HB Decision # 1: Use Master-slave Architectural Style where slave processes are replicated Detailed Example: An architectural view 20 Decision # 2: Checkpoint updated data, and bundle replicas (send every 2 seconds) – in order to meet performance goals. Decision # 3: Use heartbeat tactic to monitor availability of task trackers and data nodes. Heartbeat must beat every .25 seconds to balance availability and performance. Decision # 4: Use proxy handles failure pattern to shield clients from failures, and to support fault tolerance (i.e. service continues in the face of transient failure. Apache Hadoop Architecture Requirements# 1: highly available system, where hardware failure can be the norm rather than the exception Decision # 1: Mutual Authentication with Kerberos RPC (SASL/GSSAPI) on RPC connections Decision # 2: Maintain an Audit Trail Decision # 3: Data Encryption on RPC Data Encryption on Block data transfer Data Encryption on HTTP Decision # 4: Secure DataNode: DataNodes must authenticate themselves Requirements# 2: Provide secure services for the client More Decisions: A non-trivial architecture is likely to be composed of hundreds, if not thousands of architectural decisions. Decision # 1: Separate each of these domains and run them on different threads.. More Decisions: A non-trivial architecture is likely to be composed of hundreds, if not thousands of architectural decisions. Decision # 29: Separate data busses should be used for data or command operations. Each buss should utilize a different scheduling mechanisms. Decision # 101: Utilize heartbeat, voting and simulation to detect faults. FDIR module responsible for all these. Decision # 1: Keep primaries together, and replicas together at all times to meet redundancy goals. Decision # 2: Checkpoint updated data, and bundle replicas (send every 2 seconds) – in order to meet performance goals.Decision # 3: Use heartbeat tactic to monitor availability of track manager primaries and secondaries. Heartbeat must beat every .25 seconds to balance availability and performance. Decision # 3: Use heartbeat tactic to monitor availability of track manager primaries and secondaries. Heartbeat must beat every .25 seconds to balance availability and performance. Decision # 32: System must use active redundancy with graceful degradation to achieve maximum availability. More Decisions: A non-trivial architecture is likely to be composed of hundreds, if not thousands of architectural decisions. More Decisions: A non-trivial architecture is likely to be composed of hundreds, if not thousands of architectural decisions. Decision # 91: Utilize heartbeat, voting and simulation to detect faults. FDIR module responsible for all these. Decision # 1: Use thread pooling to execute recurrent mission operations. Decision # 21: Active redundancy is implemented to achieve minimize mean time between failures. Decision # 19: Separation of concerns: Each tasks must run as a separate process on a separate processor. Decision # 66: Check pointing is utilized to recover non-mission critical operations. Decision # 52: Platform Diversity plus N-Version programming must be used to maximize the reliability. Decision # 4: Use proxy handles failure pattern to shield clients from failures, and to support fault tolerance (i.e. service continues in the face of transient failure. Decision # 151: Utilize heartbeat, voting and simulation to detect faults. FDIR module responsible for all these. Decision # 81: Voting mechanism is used to recover from failure of any of the sensors. Decision # 101: Utilize heartbeat, voting and simulation to detect faults. FDIR module responsible for all these. Decision # 113: Semantic based scheduling and task sequencer is used to provide real- time performance. More Decisions: A non-trivial architecture is likely to be composed of hundreds, if not thousands of architectural decisions. Decision # 3: Use heartbeat tactic to monitor availability of track manager primaries and secondaries. Heartbeat must beat every .25 seconds to balance availability and performance. Decision # 121: Keep primaries together, and replicas together at all times to meet redundancy goals. Decision # 3: Use heartbeat tactic to monitor availability of track manager primaries and secondaries. Heartbeat must beat every .25 seconds to balance availability and performance.
  21. 21. 21 Handbooks of Software Architecture
  22. 22. Architectural StylesPatterns: 22
  23. 23. Architectural Tactics 23
  24. 24. WHY SOFTWARE ARCHITECTURE RECOVERY? 24 I always get that question: “Is there anyone who does this?”
  25. 25. 25 Why Software Architecture Recovery? 1- Software Comprehension Department of Defense (DOD) spends almost half of its post-deployment costs (47%) reverse engineering its own code. This process often involves identifying the underlying design intent in order to modify a legacy system, or understanding the code and evaluating the impact of introducing changes. Staff turn over. Buy a new software product, get insight about internal qualities.
  26. 26. 26 Why Software Architecture Recovery 2- Preserving Architectural Qualities Why Software Architecture Recovery? Intended Architecture Implemented Architecture
  27. 27. 26 Why Software Architecture Recovery 2- Preserving Architectural Qualities Why Software Architecture Recovery? Intended Architecture Implemented Architecture Requirements misunderstanding Design Violation Insensitivity to design Lack of design knowledge Inappropriate tools Bad implementations Changes
  28. 28. 28 Why Software Architecture Recovery?
  29. 29. 28 A big ball of mud: Apache Hadoop architecture Why Software Architecture Recovery?
  30. 30. 30 Why Software Architecture Recovery? 3- Renovating Architecture e.g. From Legacy System to Cloud based architecture. A- Forward Architecting to design the ideal architecture. B- Reverse architecting the legacy system to discover current architecture. C- Rebalancing, to create an architecture improvement plan.
  31. 31. https://www.youtube.com/watch?v=gp_D8r-2hwk
  32. 32. The Ariane 5 system reused design specifications and code from its highly successful predecessor, the Ariane 4. The Inertial Reference System, performed a data conversion of a 64-bit floating point value related to the horizontal velocity and place the result into a 16-bit signed integer variable. Based on the operating characteristics of the Ariane 4, the design team felt it was physically impossible to have a horizontal velocity large enough to cause an arithmetic overflow of a 16-bit signed integer variable. However, the reuse of this software in the Ariane 5 placed the code in a very different operating context in which the specific design assumption relating to horizontal velocity was no longer valid. Primary process crashed, the system switched to the redundant backup process, the backup crashed for the same reason. The Inertial Reference System then generated diagnostic output which was incorrectly interpreted as flight control data by other portions of the flight control system. This faulty interpretation made the flight control system take actions that led to the self-destruction of the rocket.
  33. 33. 33 Reverse Engineering and Design Recovery : A taxonomy, Elliot J. Chikofsky, James H. Cross II, IEEE Software, January 1990 What to Recover?
  34. 34. 34 Quality Function Deployment’s House of Quality Functionaliti es Relationships Between Qualities and Design Decisions ImportanceRankingsQualities Design Decisions Costs/Feasibility Engineering Measures Trade-offs 1 2 3 4 5 6 7 8 What to Recover?
  35. 35. How to Recover the Architecture?  We need a chain of evidences to discover the decisions and reconstruct the architecture  It’s not about mining code, it’s about mining software repositories, mining all assets. 35 …. Code models Bugs Issues Changes Documents Specifications People ChatsTraces Web Sites Emails
  36. 36. …. Code Models Bugs Issues Changes Documents Specifications People ChatsTraces Web Sites Emails Partial Views Pieces of knowledge Decision View Logical View Deployment View Physical View Process View Use case View How to Recover the Architecture? 36
  37. 37. How to Recover the Architecture?
  38. 38. RECOVERING TACTICAL ARCHITECTURAL DECISIONS 38
  39. 39. How to Achieve this? 39  Tactics are pervasive in fault-tolerant and/or high- performance systems.  Tactics seem to have an interesting relationship to change.
  40. 40. Use of Tactics in a Variety of Systems 40 Tactics tend to be found in safety-critical, and/or other kinds of performance-centric systems.
  41. 41. Why It is so Difficult? 41 No single way to implement an architectural tactic/decision. Structural analysis fails. ❸ Observer Pattern (Found in Amalgam) ❷ Decorator Pattern (Found in Thera, JSRB, Rossume) ❶ Direct communication with Configuration (Found in Hadoop, Chat3, Smartfrog) Mehdi Mirakhorli, Jane Cleland-Huang, "Tracing Architectural Concerns in High Assurance Systems (NIER Track)“, 33th International Conference on Software Engineering, ICSE 2011, Honolulu, Hawaii, USA, May 2011.
  42. 42. It’s Even Harder 42 A big ball of mud: Apache Hadoop architecture
  43. 43. It’s Even Harder 43 A Closer Look at Apache Hadoop - Pooling Tactic
  44. 44. Recovering Architectural Tactics 44 Mehdi Mirakhorli, Yonghee Shin, Jane Cleland-Huang and Murat Cinar, "A Tactic-Centric Approach for Automating Traceability of Quality Concerns", IEEE International Conference on Software Engineering (ICSE) 2012, (14% acceptance).ACM SIGSOFT Distinguished Paper Award.
  45. 45. Tactic Detection Approach 45 Normalizes the frequency with which term t occurs in the training document with respect to its length Computes the percentage of training documents of type Q containing term t Decreases the weight of terms that are project specific. Training Classification Computes the likelihood that code snippet r traces to Query q.
  46. 46. HADOOP Case Study 46 Approximately 1700 classes.
  47. 47. RECOVERING MODULE VIEW 47
  48. 48. Recover Implementation View  Static dependency checkers  Structure 101, Lattix, CppDepend, Ndepend  jDepend, ClassCycle, Dependency Finder  Understand C++, Bauhaus, SonarJ, Softwarenaut  Reveal real structures via dependency analysis 48
  49. 49. Example: Hadoop Yarn View 49
  50. 50. Code City 50
  51. 51. 51  Details on the overall Class density  Identification of God Classes Code City
  52. 52. 52  Details on the overall Class density  Identification of God Classes Code City  What is that green parking lot?
  53. 53. Code City 53  What is that green parking lot?
  54. 54. Code City 54
  55. 55. 55  Identification of major Components  Filtration based on the percentage of dependency  Class hierarchy Softwarenaut Main components like Node-Manager and Resource-Manager do not have dependency on each other. http://scg.unibe.ch/softwarenaut
  56. 56. 56 Softwarenaut Filter the dependencies by 40% and try simplifying the dependency graph.
  57. 57. 57 Understand Tool
  58. 58. 58 Understand Tool
  59. 59. 59 Understand Tool
  60. 60. 60 Structure 101 Unique feature is different type of clustering
  61. 61. 61 Structure 101 10 packages have been clustered together because all of them have cyclical dependency with each other.
  62. 62. 62 Top Down/Conceptual/Reflection Model  Start with Specifications / High level knowledge about architecture  Formulate hypotheses and verify them against the source code Gail C. Murphy, David Notkin, and Kevin Sullivan. 1997. Extending and Managing Software Reflexion Models. Technical Report. University of British Columbia, Vancouver, BC, Canada, Canada.
  63. 63. 63 Recovering Layers
  64. 64. RECOVERING FUNCTIONAL ARCHITECTURE 64
  65. 65. Recover Functional Architecture Functional architecture is a conceptual view of the architecture, depicting the key areas of functionality in the system and how they interact with each other. 65
  66. 66. Recover Functional Architecture Cluster features, tasks, change requests, bugs etc. submitted to JIRA issue tracking system. 66
  67. 67. Recover Functional Architecture Incremental Diffusive ClusteringSubmitted Issues Feature Naming Code-Feature Correlation Source Code Features NamesFunctional Elements 67 Features
  68. 68. Recover Functional Architecture translat, framework, correct, dutch, timesheet, spanish, Translate statu, account, cancel, fin, reconcili, tran Accounting payment, gatewai, deposit' Payment invoic Invoice mgm order, item, purchas, quot' Order cart, shop' Shopping modul, hr, leav' HR ship, shipment, field, group' Shipment email, contact, address, mech, notific' communication inventori, facil, receiv, serial' Inventory mgm birt, russian, persian, declar, effici' Language card, credit, number' Credit Card Processing task, project, mgr, projectmgr' Project mgm effort, workeffort, note, work Workefort mgm supplier, vendor' Supply mgm 68
  69. 69. Recover Functional Architecture 69
  70. 70. RECOVERING DESIGN PATTERNS 70
  71. 71. Discovery Micro Design  Stage 1: Creating semi-formal definitions for each pattern of interest and its variants based on common extensible feature types.  Stage 2: Detecting patterns by identifying its features, with different search technologies best fitting to the respective feature. Slide used courtesy of Patrick Maeder 71
  72. 72. ONE BIG CHALLENGE 72
  73. 73. 72 Architecture Decay
  74. 74. 72 A big ball of mud: Apache Hadoop architecture Architecture Decay
  75. 75. ONE SCENARIO: PRESERVING THE ARCHITECTURE 75
  76. 76. Architecture Breaker 76Issues Reported: HADOOP-4584, HADOOP-178,… NameNode.java DataNode.java a)HeartBeat b)blockreports c)blocktobe deleted … Developer #1: DataNodes.java, should send several messages to the NameNode.java. Messages such as block reports, heartbeat, blocks to be deleted etc. Dat a Dat a Dat a
  77. 77. Architecture Breaker 76Issues Reported: HADOOP-4584, HADOOP-178,… NameNode.java DataNode.java a)HeartBeat b)blockreports c)blocktobe deleted … Developer #2: So many messages, lets merge them by piggy-backing Dat a Dat a Dat a
  78. 78. Architecture Breaker 76Issues Reported: HADOOP-4584, HADOOP-178,… NameNode.java DataNode.java a,b,c,… Piggy Backing Heartbeat message on block reports Developer #2: So many messages, lets merge them by piggy-backing Dat a Dat a Dat a
  79. 79. Architecture Breaker 76Issues Reported: HADOOP-4584, HADOOP-178,… NameNode.java DataNode.java a,b,c,… Piggy Backing Heartbeat message on block reports Developer #2: So many messages, lets merge them by piggy-backing Design Decay & Compromising Availability: Block reports are usually delayed, system detects the DataNode failure and lunches the recovery process while it is alive. Dat a Dat a Dat a
  80. 80. Architecture Breaker 80Issues Reported: HADOOP-4584, HADOOP-178,… NameNode.java DataNode.java … a.b.c…. If (t==10 & BlockReady) report(b); else report(Empty); Developer #3: every 10 seconds DataNode reports data or send an empty message for heartbeat Dat a Dat a Dat a
  81. 81. Architecture Breaker 81Issues Reported: HADOOP-4584, HADOOP-178,… NameNode.java DataNode.java a.b.c…. If (t==2 & BlockReady) report(b); else report(Empty); Developer #4: lets make it every 2 seconds Design Decay & Performance Tradeoff: Performance issues, tradeoff between availability and performance Dat a Dat a Dat a
  82. 82. Archie: A Smart IDE to Protect Architecture The vision initially presented at: Mehdi Mirakhorli, Cleland-Huang, "Using Tactic Traceability Information Models to Reduce the Risk of Architectural Degradation during System Maintenance", ICSM 2011. 82
  83. 83. Detect and monitor code snippets that implement key architectural decisions in the source code. Proactively keep developers informed of underlying architectural decisions during maintenance activities. Automatically trace external architecture specification documents to the source code or design model. Perform change impact analysis of architectural concerns at both the code and design level. 83 Archie: A Smart IDE to Protect Architecture
  84. 84. Decision Detector: A rigorously validated automated technique based on a combination of machine learning, structural analysis, and pattern matching techniques. Why it works?: Trained by sample source codes from hundreds of open source projects. 84 Detect and monitor code snippets that implement key architectural decisions in the source code. Archie: A Smart IDE to Protect Architecture Code Snippets public boolean isAuditUserIdentifyPresent(){ return(this.auditUserIdentify != null); public BigDecimal getAuditSequenceNumber(){ return(this.auditSequenceNumber; Code Snippets public boolean isAuditUserIdentifyPresent(){ return(this.auditUserIdentify != null); public BigDecimal getAuditSequenceNumber(){ return(this.auditSequenceNumber;
  85. 85. 85 Detect and monitor code snippets that implement key architectural decisions in the source code. Archie: A Smart IDE to Protect Architecture
  86. 86. 86 Detect and monitor code snippets that implement key architectural decisions in the source code. Archie: A Smart IDE to Protect Architecture
  87. 87. 87 Proactively keep developers informed of underlying architectural decisions during maintenance activities.  IDEs and Compilers do well on Syntactical issues, a little attention to Semantic but Design Rational is not covered. Archie: A Smart IDE to Protect Architecture  Archie has features for communicating architectural knowledge.  Visualization module to depict the seams of a software design, the driving requirements, business goals and rationale behind the source code.
  88. 88. 88 Archie: A Smart IDE to Protect Architecture Proactively keep developers informed of underlying architectural decisions during maintenance activities.
  89. 89. Perform change impact analysis of architectural concerns at both the code and design level. An asynchronous Event-Based monitoring and notification infrastructure has been designed to proactively inform developers of underlying architectural decisions. An initial proof of concept experiment has been conducted. Archie: A Smart IDE to Protect Architecture 89
  90. 90. 90 Archie: A Smart IDE to Protect Architecture Perform change impact analysis of architectural concerns at both the code and design level.
  91. 91. 91 Archie: A Smart IDE to Protect Architecture Perform change impact analysis of architectural concerns at both the code and design level.
  92. 92. 92 Archie: A Smart IDE to Protect Architecture Design Warnings Perform change impact analysis of architectural concerns at both the code and design level.
  93. 93. WHAT ARE YOU PASSIONATE ABOUT? 93
  94. 94. Software Archeology Mehdi Mirakhorli, Rochester Institute of Technology Winter 2015 Software Architecture Reconstruction: Why? What? and How? 94

×