The goal of our AI assistant, named PatternPartner, is to analyze logs from running programs (such as Network Packages, Docker Outputs, and System Calls) and identifying architectural patterns within software systems, helping developers to know the current design and system optimizations implemented, making room for thoughts on what is right and wrong, and how to improve them.

Table of Contents

• Vision
• Domain Analysis
• Architecture & Design
• Technologies
• Development Guide
• How to Use
• Contributions
• Sprint 1 - Backlog Items
• Sprint 1 - Sprint Retrospective
• Sprint 1 - Happiness Meters
• Sprint 2 - Backlog Items (end of sprint)
• Sprint 2 - Sprint Retrospective
• Sprint 2 - Happiness Meters
• Sprint 3 - Backlog Items (beggining of sprint)
• Sprint 3 - Backlog Items (end of sprint)
• Sprint 3 - Sprint Retrospective
• Sprint 3 - Happiness Meters

Vision

Our product is aimed at developers that want to enhance their software architecture analysis process, making it easier to understand the underlying architectural patterns in their systems. This makes it possible for developers to ensure that they align with best practices estabilished in the market and makes it easier to make decisions on how what to improve from the current status.

To achieve this objective, artificial intelligence is used through Google's Gemini API. For each log analyzed, there will be a division in subcategories that match the patterns found by the LLM, all of which will contain a general description. This is important to keep in mind, since the LLM will not be analyzing in-depth each and every scenario, for that would require more than the free-to-use plan of this API.

PatternPartner, although meant to be used mainly by developers, can also be used by students or curious tech-people that want to have a general look at a given program architectural structure. This is made possible since the logic behind the analysis is not required to be understood to retrieve valuable information from this assistant, making it easier to get useful information even for those who lack knowledge or experience.

Domain Analysis

• Log Collector: Handles various log types (Network Packages, Docker Outputs, System Calls).
• Pattern Detector: Runs the AI model for pattern detection based on input logs.
• Pattern Catalog: Subdivision of the results according to categories established in literature (such as POSA4).
• Report Generator: Prepares analysis results in Markdown format (both for direct visualization and download to keep this information stored).

Architecture & Design

Our AI assistant is built based on a layered approach, where we have:

• User (actor): interacts with the assistant by providing logs, requesting analysis and viewing results.
• Interaction Layer (frontend component): allows the user to upload their logs and communicates with the analysis layer, showing the results as a Markdown output on screen and allowing the user to store it locally.
• Analysis Layer (backend component): powered by Google's Gemini LLM, this layer is responsible for the detection of architectural patterns.
• Data Storage Layer (backend component): allows the user to get his previous record of Markdown outputs.

Technologies

PatternPartner uses Node.js for the backend and React for the frontend, making it easier to integrate the LLM with a web application interface, enabling users to interact with the system through a modern, responsive UI. The main technology stack includes:

Backend (Node.js):

• Log Collection: enables users to input the logs from their running programs and prepares them to be sent to the LLM.
• Pattern Detection: performs pattern detection based on the given logs through the use of Gemini API.
• Output: formats the analysis output results in Markdown to enable a smooth and easy reading.

Frontend (React):

• User Interface: a responsive and user-friendly UI for inserting logs and starting the execution of the process with the click of a button.
• Data Output: the output will be displayed to the user in the format of a Markdown file, ready for download with a single click of a button that allows the user to keep track of this information locally.

Prototype

The initial prototype in Sprint 0 integrated basic log analysis from a given log input and initial contextualization given to the LLM, and the pattern detection was made through the use of OpenAI LLM. For result display, the LLM output was formatted as a Markdown file that contained the categories of architectural patterns detected and their general description. With more research made, the transition to Gemini LLM was found necessary due to stricter limitations of the free-to-use OpenAI API.

This prototype made it possible to see the need for automation and user-friendly use of this tool, since having to always contextualize the LLM manually and letting it know how the output should be made can become tedious and complicated. By automating this, not only it is less error-prone, but also gives the user more free time to focus on other important aspects of their field.

Development guide

The main ai4sd frontend is written in JS and uses React.js logic to operate. If you follow the "assistant/patternpartner" branch, under "avengers/frontend/webapp/src/app" there are all the main shared components and styling that make it work. Inside that, under "assistants/patternpartner" there is the content of our frontend logic implementations, together with a README file that has simple instructions on how to test the frontend in separate. The connection to the backend is not implemented since the cloud integration of our assistant was not achieved (see Sprint 3: Retrospective).

The backend we developed is under "superheroes/superhero-06-04". It contains all the logic that was tested in our own repository, T06_G04 (see Sprint 3: Retrospective for details why it's like this instead of testing in main), and it uses Next.js to operate.

Our assistant uses Gemini API, allowing the logs inserted by the user to be sent to an LLM. It, together with our code, breaks it down into smaller chunks and perform the analysis regarding software architectural patterns, delivering to the user the final results without the need of taking time into doing prompt engineering.

Commenting how the functions work in the code was also a focus and successfully achieved, improving the readability of the whole code and allowing for future maintenance to be more straightforward. There was also concern about styling (such as proper spacing and line breaks) and naming functions and variables in a way that would make it easier to understand the logic implemented.

Tools:

Node.js and React are the foundation of this project.

• Node.js is a well-stablished open-source software that is recognized for its asynchronous architecture and for being event driven. By being single-thread, Node.js only uses one thread that is responsible for executing the JavaScript code. Everything related to the backend will be developed using Node.js.

• The frontend will be supported by React, a free and open-source JavaScript library for building user interfaces.

API:

We will be using Google's Gemini API since it's free and capable of processing large chuncks of data (logs) at once.

• Gemini is a family of multimodal large language models developed by Google DeepMind.

Formats:

Our app will receive log files as inputs and after processing all data and acknowledging patterns it will generate an output text on all the patterns recognized during the analysis as well as a description about all of them. The User can also download a Markdown file that contains the output report.

How to use

PatternPartner is an assistant designed with simplicity and usability in mind, making it accessible for developers, students, and tech enthusiasts to understand the architectural patterns within a software system. We’ve prepared a few steps for the user to follow:

Step 1: Access PatternPartner

1. Open PatternPartner tab on the main web app interface.
2. Once you’ve opened it, you will arrive at the main dashboard, where you can input log files for analysis.

Step 2: Input Logs

1. Click the "Choose Files" button.
2. Choose the log file you wish to analyze.
3. Once uploaded, confirm the log details and ensure they’re ready for analysis.

Step 3: Initiate the Analysis

1. Click the "Upload File" button to begin the process. PatternPartner will use Google’s Gemini API to detect and analyze patterns within the logs.
2. During analysis, you may see a Loading Indicator showing that the app is still processing the request.

Step 4: View and Download Results

1. Once analysis is complete, PatternPartner generates a Markdown report that categorizes detected patterns and includes a description for each.
2. You can review the report directly within the application or download it to keep a record of the analysis.
3. Use the Download Report button to save the Markdown file locally, allowing you to revisit the insights whenever needed.

Step 5: Interpret Results and Plan Next Steps

1. Review the report’s architectural breakdown to assess your system’s alignment with established best practices.
2. Leverage the categorized insights to identify areas for potential optimization, improvement, or redesign.

Additional Tips

• Iterate: Regularly run PatternPartner as your system evolves to maintain a current understanding of your architectural patterns.
• Explore Different Logs: Upload logs from various sources to gain a comprehensive view of your system’s architecture.

Contributions

Link to the factsheets of each team and of each team-member: Team 4

• Daniel Nunes (PO)
• Henrique Caridade (SM)
• Pedro Pinto
• Rui Martins

Sprint 1 - Backlog Items

The first image illustrates the overall view of the Backlog Board, and from images 2 to 5 is the representation of the remaining PBIs.

Sprint 1 - Sprint Retrospective

• Before the individual questions, it is important to note that most of the work accomplished is working only in the team repository, T06_G04, instead of the general ai4sd, since the development and testing has been done locally due to complications with deploying everything correctly to the main infrastructure and the cloud.

---

---

1. What did we do well?

• Daniel – I don’t think there was a thing that went well in this sprint. Almost no one showed commitment to get things done. As a Product Owner, I represent our team, but it is impossible to be representing and guiding a team that doesn’t collaborate. Despite that, I tried to make a small setup of a base exemple so that the developers could have something to work on.
• Henrique – ?
• Pedro – ?
• Rui – During the first sprint, I focused on learning as much as possible, diving into tools and frameworks like Docker, Node.js, and React. Coming from a non-Bachelor’s background, there were many concepts and tools I hadn’t encountered before. This sprint was essential for understanding the project and getting a broad overview. However, it wasn’t the most productive sprint in terms of implementing what I learned. Progress on the project was limited, and the sprint felt more like an individual learning experience rather than a team-focused effort.

---

2. What can we do better?

• Daniel – In my opinion, most of the sprint went bad and there are a lot of aspects that can be improved. There was little commitment to the actual project from the development team, and there was a clear absence of the Scrum Master in the whole process. Communication was very difficult and there was a clear lack of interest on getting things done. As the Product Owner, my role is hard to do when the team is not actively trying to get things done, since I can’t improve if there is no activity and no feedback from my team regarding whether everyone agrees about the product vision and the organization/relevance of the Product/Sprint Backlog Items.
• Henrique – ?
• Pedro – ?
• Rui – As I mentioned in TPC 5, the team needs to be significantly more communicative and collaborative. Currently, there’s minimal interaction between team members, and everyone seems to be working independently (at least some of us). This lack of synchronization makes tasks take much longer than they should, as we’re often not aligned or working towards the same goals.

---

3. What are things we aren’t sure as of now?

• Daniel – Right now, I’m not sure how we will be able to integrate our assistant with the general structure, and if it would be possible/interesting to merge PatternPartner with other assistants from the architecture area.
• Henrique – ?
• Pedro – ?
• Rui – I’m still trying to fully understand how the shared backend operates and how we’ll integrate our assistant’s backend with the broader system. These aspects remain unclear and require further exploration.

---

4. What can we work on right at the beginning of Sprint 2?

• Daniel – I would say that it’s important that communication starts flowing and everyone starts doing their part. When that happens, the integration of our assistant with the general structure would be a massive step forward, considering the lack of content we have to show so far.
• Henrique – ?
• Pedro – ?
• Rui – It’s crucial to prioritize completing the file upload system and ensuring we can get a response from Gemini. Achieving this would give us a glimpse of what the final version of the assistant might look like, which could significantly boost team motivation and provide a clearer direction moving forward.

Sprint 1 - Happiness Meters

This is organized in a list format, with the following scale of satisfaction:

• Nothing to Show (0/5)
• Bad (1/5)
• Below Average (2/5)
• Average (3/5)
• Good (4/5)
• Very Good (5/5)

---

1. Daniel evaluating:

• Daniel - 4
• Henrique - 0
• Pedro - 0
• Rui - 4

---

2. Henrique evaluating:

• Daniel - ?
• Henrique - ?
• Pedro - ?
• Rui - ?

---

3. Pedro evaluating:

• Daniel - ?
• Henrique - ?
• Pedro - ?
• Rui - ?

---

4. Rui evaluating:

• Daniel - 5
• Henrique - 0
• Pedro - 0
• Rui - 4

---

Sprint 2 - Backlog Items (end of sprint)

Sprint 2 - Sprint Retrospective

• Before the individual questions, it is important to note that most of the work accomplished is working only in the team repository, T06_G04, instead of the general ai4sd, since the development and testing has been done locally due to complications with deploying everything correctly to the main infrastructure and the cloud.

---

---

1. What did we do well?

• Daniel – In this second sprint there was a good progress towards "making it happen" when it comes to the functionalities expected from our assistant. Despite the absence of both Henrique and Pedro, I was still able to get feedback on improvements about the ranking and overall classification of the backlog items. I think the overall collaboration between me and Rui was good, and I managed to clarify what functionalities I expect our product to have, as well as communicate with our APO on how to proceed regarding several development aspects.
• Henrique – ?
• Pedro – ?
• Rui – I believe this sprint went as planned in terms of getting the work done. As a dev I could finally implement and work on some features that I have been studying during the whole semester. When it comes to communication it was also an incredible sprint both in relation to communication between me and Daniel (PO) and communication between me and members of other groups. It was great to learn new things from different members of this course.

---

2. What can we do better?

• Daniel – I believe that attempting to estabilish communication with other teams would be benefitial to get things flowing more easily, especially regarding the whole process of integration our assistant with the cloud architecture. It would also be ideal if both Henrique and Pedro could put effort into helping with the development and integration of our assistant, since this is not an easy task to accomplish with only 2 members actively working.
• Henrique – ?
• Pedro – ?
• Rui – We should focus mainly on the essential features that compose our assistant and that make the user's experience way more interesting and engaging. It would be better to test the assistant in different scenarios as well since we have always used the same log files.

---

3. What are things we aren’t sure as of now?

• Daniel – Currently, despite a lot of clarifications with our APO, I still find that integrating our assistant in the cloud is not going to be an easy task, and we will probably find some unknown setbacks during that process.
• Henrique – ?
• Pedro – ?
• Rui – As Daniel mentioned I think the integration in the cloud will be the hardest part. I have already an idea on how to execute everything however some issues might occur during the process.

---

4. What can we work on right at the beginning of Sprint 3?

• Daniel – There are some minor things to address with the logic of the assistant so it can perform better and in a more appealing way. Also, I would say that the process of integrating our assistant with the cloud is a very important but difficult step to achieve, and that it would make the whole team proud of all the accomplished work if we manage to make it work.
• Henrique – ?
• Pedro – ?
• Rui – For now we should try to fix some issues or inefficient parts of the assistant before we go ahead and try to properly integrate the assistante in the cloud.

Sprint 2 - Happiness Meters

This is organized in a list format, with the following scale of satisfaction:

• Nothing to Show (0/5)
• Bad (1/5)
• Below Average (2/5)
• Average (3/5)
• Good (4/5)
• Very Good (5/5)

---

1. Daniel evaluating:

• Daniel - 5
• Henrique - 0
• Pedro - 0
• Rui - 5

---

2. Henrique evaluating:

• Daniel - ?
• Henrique - ?
• Pedro - ?
• Rui - ?

---

3. Pedro evaluating:

• Daniel - ?
• Henrique - ?
• Pedro - ?
• Rui - ?

---

4. Rui evaluating:

• Daniel - 5
• Henrique - 0
• Pedro - 0
• Rui - 5

---

Sprint 3 - Backlog Items (beggining of sprint)

Sprint 3 - Backlog Items (end of sprint)

Sprint 3 - Sprint Retrospective

• Before the individual questions, it is important to note that most of the work accomplished is working only in the team repository, T06_G04, instead of the general ai4sd, since the development and testing has been done locally due to complications with deploying everything correctly to the main infrastructure and the cloud.

---

---

1. What did we do well?

• Daniel – In this last sprint we tried to deploy what we had in the cloud, as well as refine the assistant itself. The first point was not properly achieved since the team has a severe shortage of members, and despite having good internal communication we tried to reach out to other colleagues for help but got no success. Regarding the refinement, there was progress but not as much as we wanted to. Overall things could have gone better, but I think it was not too bad.

• Rui – In this third and last sprint we focused mainly on the key features and general optimization of the assistant. Fortunately, we implemented almost every feature we planned eventhough the assistant was not deployed succesfully. Overall, DS was a great opportunity to learn different tools and interact with new colleagues.

---

2. What could we have done better?

• Daniel – While we did have good internal communication, we tried but failed to reach out to other colleagues for help. Despite that, I failed to bring our complications to our APO sooner, which made our assistant not be integrated in the cloud, which was an important part of the project.

• Rui – Honestly we could have avoided some major issues regarding the group and the product itself by communicating a lot more with other teams and members of this course. Despite being a smaller group compared to the others, we had the potential to achieve a better product.

Sprint 3 - Happiness Meters

This is organized in a list format, with the following scale of satisfaction:

• Nothing to Show (0/5)
• Bad (1/5)
• Below Average (2/5)
• Average (3/5)
• Good (4/5)
• Very Good (5/5)

---

1. Daniel evaluating:

• Daniel - 3
• Rui - 4

---

2. Rui evaluating:

• Daniel - 4
• Rui - 4

---