[2/2] Deductive Software Architecture Recovery via Chain-of-thought Prompting (Category Architecture)
Continue. story about the SAR deductive process (Software Architecture Recovery) With the help of LLMs, I will tell you in my own words about the steps of this process.
Phase 1. Reference architecture definition In fact, this phase is added by the authors and allows you to add the use of LLMs.
- Select reference architecture - here the authors propose to choose a reference architecture, the standard layered architectuure, MVC are mentioned, but immediately you can recall other approaches of the type MVVM, Onion Architecture, etc.
- Define architectural components Here the authors define the components of the architecture, they will be used by LLMs for further code classification. For example, for a typical layered architecture, the following levels are allocated: presentation, application service layer, etc. 3)Define component & interaction indicators - here the authors in text form describe the rules of interaction of components, which is further used for classification. For example, in the case of layered architecture, the authors describe the properties of the presentation layer.
Pr1 . . sets the attributes of UI components, e.g., sets the text of a TextView. Pr2 . . . notifies listeners about user events, such as button clicks or list item selections. Pr3 . . . transforms domain objects into visual representations
Phase 2. Code unit classification This phase is recursive and directed from the bottom up. The authors suggest choosing granularity, and then running the classification. For example, start with class methods, then aggregate this into classes, then into nemespaces, and so on. 4) Evaluate code units against indicators In fact, here a little prompt engineering + code with descriptions of methods falls into the LLM. (GPT-4) assessment for classification by components from reference architecture
In a layered software architecture, one of the layers is the (layer_name) layer, which (layer_responsibility). Consider the context of an Android Java project “(project_name)”: (project_domain_description) Here are some indicators that a Java method in the project may belong to a class in the (layer_name) layer: (layer_indicators) The class ‘(class_name)’ contains the method ‘(method_name)’: (method_source_code) Check whether this method satisfies each indicator above. Mention the specific line of code that supports your reason. At the very last line, write the boolean verdicts separated by a comma, e.g., ‘true, true, false, true’. If indeterminate, say ‘false’.
- Aggregate classified code units Here we aggregate the answers from the previous stage and get the classes in which the methods were, and then run them to the previous step for reclassification and so on until we get to the desired level of abstraction.
At the end of this process, we get some classification of software components, taking into account the reference architecture of our project. The authors made a PoC for Android app K9 Mail and compared manual markup experts with what the model counted - precision and recall for classification were 72percent 71%, respectively. As a result, the authors noted that there is still room for improvement and formulated their plan for further research, including work on reference architectures, as well as field research in companies using this method.
#Architecture #Software #Metrics #LLM #AI #ML #Engineering #RnD