Customer Milestone 2 ‐ Project Deliverable

Introduction

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:

1. Executive Summary

1.1) Summary of Project and Current Status

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!

1.2) The Status of Implementation

1.2.1 Release

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

1.2.2 Deployment

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.

1.3) The Status of Deliverables

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

1.4) Meeting Notes Regarding to this Milestone

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

1.5) Challenges as a Group

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.

1.6) Evaluation of Tools Used in the Project

1.6.1) Github

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.

1.6.2) Discord

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.

1.6.3) Whatsapp

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.

1.6.4) ProjectLibre

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.

1.6.5) Figma

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.

1.6.6) Visual Studio Code

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.

1.6.7) Mermaid

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.

1.6.8) drawio

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.

1.7) Evaluation of Processes Used in the Project

1.7.1) Team Meetings

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.

1.7.2) Separations of Responsibilities

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.

1.7.3) Implementation

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ğ, Oğuz Hekim, Mustafa Ocak was responsible from the backend application and database alongside with 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.

2. Contributions of Contributing Members

2.1) Deniz Bilge Akkoç

2.1.1) Contribution Descriptions

2.1.2) Challenges

I learned a bit of everything, a little react a little react native but had problems with implementing a running project and asked my team members help.
During sequence diagram designing I had to reread requirments and user diagram and database model to design a correct sequence diagram so there were multiple sources and they contain some ambiguity and flaws. Therefore I consult my team members to correct those and it took some time.

2.2) Abdulsamet Alan

2.2.1) Contribution Descriptions

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

2.2.2) Challenges

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.

2.3) Mert Cengiz

2.3.1) Contribution Descriptions

2.3.2) Challenges

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.

2.4) Asım Dağ

2.4.1) Contribution Descriptions

Number	Contribution	Link
1	Contributed to decision of Database Management System and Database entities	#38
2	Decision on Backend Libraries	Check readme file
3	Initialize Backend Application	PR#57
4	Create Dockerfile for Backend	Go to commit
5	Contribute docker-compose.yml to start Backend application	#43
6	Implement Login and Signup in Backend application	PR#57
7	Implement database models creation in Backend application	PR#57
8	Implement Login and Signup in Mobile application	74, PR#76
9	Implement Authentication and routing in Mobile application	74, PR#76
10	Contribute to search algorithm in Backend application	68, PR#69
11	Connect search bar of Mobile application to Backend	74, PR#76
12	Create readme.md for the Backend	82, PR#87

2.4.2) Challenges

I learned that deciding the technologies to use at the beginning of a project could be tough. For example, I contributed to the technologies that will be used in backend application and I have never used Django before. But the team was familiar with that technology and I could get used to that.

For the implementation part challenging part was learning how to design the architecture in Django. I used to work with Javascript and Express. Since I knew the basics of Backend implementations, the only challenge in implementation was getting used to the syntax.

Also I had never had experience with Mobile part. So connecting the mobile apps functions to the endpoints I created in backend was a little challenging. But thanks to my teammates, I completed my task successfully.

2.5) Oğuz Hekim

2.5.1) Contribution Descriptions

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

2.5.2) Challenges

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.

2.6) Mustafa Ocak

2.6.1) Contribution Descriptions

Number	Contribution Description	Link
1	Created initial class diagram with the team members	Class Diagram
2	Created initial use-case diagram with the team members	Use-Case Diagram
3	Created sequence diagrams (login, register and search use-cases) with the team members.	Sequence Diagrams
4	Initialzed Backend part of the app using Django with other team members	PR#57
5	Implement login and singup page in the backend with their database models with other team members	PR#57
6	Write and revised models for backend part in Django with other team members	PR#57

2.6.2) Challenges

Creating class diagrams at first was hard due to complexity and sub-parts of the application. Luckily we were able to divide the team members and worked collaboratively with draw.io and handled this in a feasible way.
Learning Django for backend part, containerizing with docker, also connecting tho whole app, was not easy for me, I have much more to learn about fundamental software principles, most of the concepts were new to me and I wished I had more time to learn them.

2.7) Eren Pakelgil

2.7.1) Contribution Descriptions

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

2.7.2) Challenges

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.

2.8) Hanaa Zaqout

2.8.1) Contribution Descriptions

Number	Contribution	Link
1	Contributed in building the Class Diagram	Class Diagram
2	Contributed in building Use-Case Diagram	Use-Case Diagram
3	Discussed changes to Sequence Diagrams 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

2.8.2) Challenges

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.

🏠 Home
🖥️ Demo Tips
📝 Plan
📝 Project
📝 Customer Milestone Reports
✨ Team Members
- Abdulsamet Alan
- Asım Dağ
- Deniz Bilge Akkoç
- Eren Pakelgil
- Hanaa Zaqout
- Mert Cengiz
- Mustafa Ocak
- Oguz Hekim
- ~~Ahmet Ayberk Durak~~
- ~~Dağlar Eren Tekşen~~
📋 Templates
📆 Meeting Notes
🥼 Lab Reports

Cmpe 352 Archive