-
Notifications
You must be signed in to change notification settings - Fork 3
Customer Milestone 2 ‐ Project Deliverable
This is the second milestone report of the Group 7 of bounswe2024. This group of CMPE352 Introduction to Software Engineering Course intends to build a software called Artifact which semantically browses for any painting existing in exhibitions or museums as well as enabling users to create their own paintings and interact with each other with their art talent. The contributed members of this project are:
- Abdulsamet Alan
- Deniz Bilge Akkoç
- Mert Cengiz
- Asım Dağ
- Oğuz Hekim
- Eren Pakelgil
- Mustafa Ocak
- Hanaa Zaqout
- Dağlar Eren Tekşen
Artifact is a social media platform that will make finding the paintings and sharing art works with others easier. It’s main domain is paintings and the project not only uses Wikidata as main data source but also gives users a platform to share their paintings with each other. So main objective is connecting everyone with every painting.
In order to achieve this, we have designed and right now developing an app which is open to both guest users who are looking for any art piece that they saw in museums and registered users who wants to share their art. The app currently allows users to semantically search and browse informations related to any art work by their names, genres, artists, even movements! The registered users also will be able to post their works with users and link them with related paintings.
Currently, we are able to register and login to the system, make necessary operations in the database regarding to register and login, and make searches with the name, genre, and movement about paintings, which return images. The home, login, register, and seaarch pages are all available in both the Web and the Mobile version, which at the end connected to the same backend system. Our system is Dockerized and deployed right now.
For us, some students who respect the effort put into any work of art, there should be better niche platforms to inspire people. Everyone should be able to search and see every painting that ever created and value the exertion. So here we are to solve this!
We have completed the deliverables for the Milestone 2. The release tag for the application is can be seen from the link: https://github.com/bounswe/bounswe2024group7/releases/tag/v0.1
We have deployed the backend and frontend applications to Google Cloud Platform service Cloud Run. The required commands can be seen in the readme.md files in frontend and backend folders. Cloud Build simply builds the images using the Dockerfile included in the folders.
The deployment URLs are:
Artifact Backend Application - https://artifactbackend-yslcfqdwna-oa.a.run.app/
Artifact Frontend Application - https://frontend-yslcfqdwna-oa.a.run.app/
We used Google Cloud CLI to deploy our applications to Cloud Run. We couldn't create a CI/CD pipeline for the autonomous build, test and the deployment of the application because of the insufficient permissions.
| Deliverable | Progress | Link |
|---|---|---|
| Responsibility Assignment Matrix | Delivered and Completed | RAM |
| Updated Project Plan | Delivered and Completed | Project Plan (Updated) |
| Class Diagram | Delivered and Completed | Class Diagram |
| Use-Case Diagram | Delivered and Completed | Use-Case Diagram |
| Sequence Diagrams | Delivered and Completed | Sequence Diagrams |
| Customer Milestone Report | Delivered and Completed | Second Milestone Report |
| Meeting Number | Link |
|---|---|
| Meeting 8 | Meeting Notes - 8 |
| Meeting 9 | Meeting Notes - 9 |
| Meeting 10 | Meeting Notes - 10 |
| Meeting 11 | Meeting Notes - 11 |
| Meeting 12 | Meeting Notes - 12 |
As the organisational problems are mostly overcome until the First Customer Milestone, the time between these two customer milestone, we have faced only one challenge in the implementation phase which is lack of information about the libraries and frameworks that we need to use. In order to progress, we have determined two ways: making specific researches followed by trying to run the code, and letting experienced members to guide the unexperienced ones.
Similarly, learning Mermaid Chart was a challenging issue as we had limited time for the designing phase according to our Project plan. The strategy for this situation was reading some example chart codes in Mermaid Chart to imitate for our cases. Moreover, our diagrams had some errors; after the meeting with the TA, we have fixed most of them.
Github is the platform that where every information regarding to our group and the project. All plans, researches, personal pages, templates, and the meeting notes are put on Github but nowhere else (Their draft might be stored on Discord). Responsibilities of the contributing group members are stored in Github Issues. Moreover, our Project is available for our Project. Additionally, in the the implementation phase, brances and pull requests are learned and efficiently used to manage the code implemented different members of the group.
Discord is the main meeting platform of Group 7. Apart from the General CMPE352 Discord server, a group-specific server is created in order to separate unrelated topics discussed alogside the group. During meetings, pages for suggestions, or any unavailability of speaking and hearing are written in their separate channels. Additionally, drafts of Agenda Items and Action Items are also stored on Discord. Similar to Whatsapp, Discord is not suitable for long-term plans, as it is not a platform that users are available very often, but information could be missed unlike Github even in Github, users are available very often, also.
Whatsapp is the secondary platform used for urgent issues such as determining the meeting hours on Sundays and caaling for members to meetings. As Whatsapp is not suitable for long-term plans, it is not preferred that much. A few non-critical problems are missed on Whatsapp; therefore, the importance of not using Whatsapp for long-term plans is learned again by experience.
This tool is used to update the Project Plan only. The ease of use to form a plan to manage the team is learned from this tool as proven not only making the plan, but also updating it.
Figma is only used to create a model that includes attributes and relations betwwen entities, but not a ER diagram, but instead an informal model, which helped to create a database, which manages the entire project of the team in an aspect.
Git version management is preferred to control the versions and the branches in the implementation phase. Since Visual Studio Code has a Git extension, branching, pulling, pushing operations could be performed in a graphical interface, which is more beginner-friendly, we have decided to use it to code this built-in syntax highlighted coding environment.
Mermaid is used to create the original and updated version of our class diagram along with each one of our sequence diagrams. We've preferred using this platform since it's easy to use, easy to learn, well documented and can be monitored and edited (although it's a premium feature) real-time. It also proved its benefits by auto adjusting the components represented by the given code and not letting us deal with their positioning and symmetry.
drawio is only used to create our Use Case Diagram although there was a strong hesitation whether to use Mermaid instead of drawio. The real-time editability of the diagram was the fundamental reason we preferred it over Mermaid for this context. We also appreciated that the diagram was being automatically enlarged as we inserted more use cases.
All meeting notes beginning from the beginning of the semester until today are available in our Wiki page. Up until now, we held two types of meetings, which are:
- Weekly meetings that's held on (mostly Sunday, some other pre-determined day if necessary) according to the outcome of the poll created on when2meet before the first customer milestone. As a group, we have understood that deterimining some other day if necessary for weekly meetings is essential to avoid fatal delays in our Project Plan
- Improvised meetings that's held dynamically and based on the specific need of a task. These meetings are not attended by the majority of the group; instead, members who has assigned to that task attends, in which way that things go faster rather than meeting with the majority of the group and doing tasks one-by-one is learned.
The total workload is separated amongst group members at weekly meetings and each task assigned to a member along with its deadline is noted in the action items of that specific meeting. We give huge importance to dividing the workload evenly. The assignee of that task is expected to open an issue related to the task after the meeting. We discuss the appropriate labels to be selected for each issue during the meeting. On the other hand, in practice, some alterations in these divisions occurred, especially in the implementation phase. Members having more experience related to the topics that we are covering went a litte bit faster compared to the non-experiences members; moreover, these members helped the others in case of emergency. As a consequence, we have learned to separate our workfore not totally equal but according to our experience and capabilities in order to keep the progress stable and in parallel.
We divided into teams as the backend, frontend, and mobile application groups. Abdulsamet Alan was responsible for the frontend application alongside with Deniz Bilge Akkoç, Asım Dağ was responsible from the backend application and database alongside with Oğuz Hekim, Mert Cengiz, Eren Pakelgil, Hanaa Zaqout completed the mobile application with the contributions of the Asım Dağ. We have divided into groups but kept contributing to each other when we faced a problem all the time. People with previous experiences led the project and tought the technologies to the other members of the team. We were actively discussing what we are going to do and what problems we are having through out the entire implementation process using Discord and Whatsapp. The team learned that we have to learn and work more to get things done since not everyone is familiar with what we are actually doing.
| Number | Contribution | Link |
|---|---|---|
| 1 | Add Pull Request Template | #39 |
| 2 | Decision on Frontend Libraries | #40 |
| 3 | Proposing Template for the Branch Names | #41 |
| 4 | Create Dockerfile for Frontend | #42 |
| 5 | Create docker-compose.yml | #43 |
| 6 | Initialize Frontend Application | #46,PR#44 |
| 7 | Deployment of the Frontend Application to Github Pages | #51 |
| 8 | Add Django-Rest-Framework to backend application | #66 |
| 9 | Deployment of Frontend and Backend Application to Cloud Run | #70 |
| 10 | Fix SPARLQLWrapper ModuleNotFoundError | #71, PR#72 |
| 11 | Create Search Bar for the frontend | 73, PR#75 |
| 12 | Update SearchBar Component for improved search | #77,PR#78 |
| 13 | Create Github Release with Tag | 80 |
| 14 | Create readme.md for the Frontend | #81, PR#84 |
| 15 | Create readme.md for the root | #85,PR#86 |
| 16 | Contributed to the database creation and models in the meetings | #55, #38 |
- The deployment process was a little bit hard because we didn't have any permission on the repository to deploy the application freely. We couldn't create a pipeline for the automations so we are deploying the applications manually with command line commands.
- The given time was really short so the team couldn't find time to learn the technologies required to finish the deliverables. Experienced people had to be active all the time to solve the problems other members faced. Also, in order the keep everyone in the same page we did meetings to teach what we are doing to the other members of the team which was a really time consuming activity.
- Because of the above reasons, I couldn't follow the best practices all the time. But we did a great job with doing the hardest parts before we completed the application. The docker files and environment setups was ready beforehand.
| Number | Contribution Description | Link |
|---|---|---|
| 1 | Contributing in creation of the Class Diagram | Class Diagram |
| 2 | Contributing in creation of the Use-Case Diagram | Use-Case Diagram |
| 3 | Contributing in creation of the First Three Sequence Diagrams, Creating Two More Sequence Diagrams | Sequence Diagrams |
| 4 | Creating a Database Table to Implement The Database Tables Easier with Eren Pakelgil | Database Table |
| 5 | Adding the Database Entities to the Backend Part by Django with Eren Pakelgil | Database Entities |
| 6 | Enabling the Wikidata Search Feature for Artifact with Eren Pakelgil | Wikidata Search Feature |
| 7 | Implementing and Improving SPARQL Queries for Better Search Feature with Eren Pakelgil | SPARQL Queries |
| 8 | Forming a Branch Having our Database Model in Django Using Git Commands | Branch issue#55 |
| 9 | Forming a Branch Having our Searching Feature in Django Using Git Commands | Branch issue#60 |
| 10 | Creating a Pull Request for the Branch Containing the Database Model | Pull Request |
| 11 | Creating a Pull Request for the Branch Containing the Database Model | Pull Request |
- Finding necessary information in SPARQL was a great challenge due to the lack of information in both the group members and the Web. By trying example queries and with the help of the groupmates, many information regardless of the necessity is returned as results of queries. Right now, we are able to return results, but in order to return only the necessary operation, extraction in SPARQL is planned by manipulating the first lines of SPARQL queries.
- Until learning the Mermaid Chart syntax completely, creating diagrams was tough. Our first diagram that we drew was the Class Diagram with fewer features available, and we had no information about how to show the interactions on Mermaid Chart. After dealing with many hours with trial-and-error, the class diagram was ready.
| Number | Contribution | Link |
|---|---|---|
| 1 | Updated our project plan and uploaded it to the wiki. | Project Plan, #45 |
| 2 | Created first version of class diagram in an online meeting with other team members. | #30 |
| 3 | Created use-case diagram in an online meeting with other team members. | Use-Case Diagram, #31 |
| 4 | Created first three sequence diagrams about login, register and search use-cases in an online meeting with other team members. | #32, #33, #34 |
| 5 | Revised class diagram and updated it to its latest version. | Class Diagram, #30 |
| 6 | Revised first three sequence diagrams and updated them to the latest version according to the feedback from TA. | Sequence Diagrams, #32, #33, #34 |
| 7 | Initialized Django backend project in an online meeting with other team members. | PR#57 |
| 8 | Revised models created by other members for the backend project. Established relations between models such as many-to-many etc. | PR#59 |
| 9 | Created endpoint and DRF view for searching functionality in an online meeting with Eren. | PR#69 |
Creating the class diagram was a challenge because we weren't sure which methods to show. Later on, we decided to avoid most of the boilerplate methods (getters and setters) to refine the diagram and show only the key functionalites of each class. Creating the first sequence diagram was also challenging because we found conflicting information from web and lecture notes. But it was clarified after the meeting with TA, and I made revisions accordingly.
For the implementation part challenging part was learning how to create endpoints in Django. But then I was introduced with Django Rest Framework and I realized it has some similarities with Spring boot, which I have some experience with. Now that I know how to write endpoints in DRF, I will work on the creation of new endpoints for the final milestone.
| Number | Contribution Description | Link |
|---|---|---|
| 1 | Contributing in creation of the Class Diagram | Class Diagram |
| 2 | Contributing in creation of the Use-Case Diagram | Use-Case Diagram |
| 3 | Contributing in creation of Sequence Diagrams #1, #8, #9, #11 and reviewing & editing Sequence Diagrams #4, #7 | Sequence Diagrams |
| 4 | Creating a Database Table to Implement The Database Tables Easier with Mert Cengiz | Database Table |
| 5 | Adding the Database Entities to the Backend Part by Django with Mert Cengiz | Database Entities |
| 6 | Enabling the Wikidata Search Feature for Artifact with Mert Cengiz | Wikidata Search Feature |
| 7 | Implementing and Improving SPARQL Queries for Better Search Feature with Mert Cengiz | SPARQL Queries |
| 8 | Forming a Branch Having our Database Model in Django Using Git | Branch issue#55 |
| 9 | Created endpoint and DRF view for searching feature with Oğuz Hekim | Branch Issue#68 |
| 10 | Creating RAM of Group 7, adding and updating the table with various tasks and meetings | RAM |
The creation of diagrams were highly challenging due to some confusions such as whether or not to include getters and setters among class methods, presence of database as an actor in Use Case Diagram, content of the arrow labels originating from user to interface and so on, yet these challenges are overcome by consulting TA and conducting useful research.
Before we came up with the idea of using SPARQL with Mert, trying to implement semantic search without its involvement caused some trouble. As for SPARQL, lack of resources and documentations about it also consumed some time while we were trying to integrate Wikidata queries into backend.
At first, I haven't been able to push a branch to the remote repo via terminal due to some authentication errors (has to be related with some critical information not given with git config command). For this reason, I've used Visual Studio Code Git extension and GitHub Desktop while interacting my local repo with the original repo.
| Number | Contribution | Link |
|---|---|---|
| 1 | Contributed in building the Class Diagram | Class Diagram |
| 2 | Contributed in building Use-Case Diagram | Use-Case Diagram |
| 3 | Discussed changed to Sequence Diagram with team members according to our discussion with TA | Sequence Diagrams |
| 4 | Created MobileApp Branch and pushed React Native mobile app Implementation for Home page that allows navigation through Login, Signup, and Search pages | #58 |
| 5 | Added README file for the mobile app part | #83 |
| 6 | Opened pull request for mobile app branch so other members can contribute to it | #65 |
It was my first experience with git commands. First when I created the MobileApp branch, it did not include the main branch files (which would create a problem when merging the branches). I spent some time getting more comfortabe with git commands to create a correct branch, pull, and push accordingly.
I would like to spend more time in backend for next milestone. As, for this milestone my concentration was mainly on fronted part, and did not have much time to explore the backend because of time limit.
-
📝 Plan
-
📝 Project
-
📝 Customer Milestone Reports
-
✨ Team Members
-
📋 Templates
Cmpe 352 Archive
-
🔍 Researches
-
📝 Project