Software Modeling and Analysis Laboratory Work Project: Music Store Music Social Network
Software Modeling and Analysis
Laboratory Work №1
Project: Music Store
Music Social Network
Functional description:
The product represents a simple social network-like application based on the music culture.
It allows users to find music and albums based on their preferences. Registered and logged in users can save preferred music and albums to their own catalogues.
On the home page users receive recommendations based on saved music and other activities.
Users can search be artist, album or song names.
They can rate music and leave comments, buy tickets for music events online.
Artists (music groups) have their profiles with brief description, style of music and average rating.
They can upload albums and appoint public events.
Technical description:
The appilication is distributed and is built upon microservices architecture.
The entire structure has features of event-driven and pipes-and-filters architectural styles. Different components communicate with each other using brockered messaging queue and event infrastructure (RabbitMQ).
Backend components are mostly separated based on use cases of the system. These include:
● UserService;
● MusicService;
● CatalogService;
● EventService;
● TicketingService;
● RecommenderService;
There are also two components, providing fundamental infrastructure:
● Common – provides messaging contracts, setup and infrastructure management;
● WebApi – application entrance point, orchestrates other services and provides endpoints for frontend;
The Web Api sends commands expecting for response without even knowing what is the handler.
Services also emit events which can be processed by one or more listeners.
The messaging brocker picks the commands and events from the exchange and routes them to corresponding consumers.
Each component has it’s own dedicated data access if needed.
The data is stored in PostgreSQL databse.
Thus, the general structure has more pronounced vertical subdivison based on use cases. Horizontal tiering is represented by fronted and backend represented by a set of services.
Project Reference
https://github.com/tomislav-m/MusicSocialNetwork
Software components used:
For messaging:
https://masstransit-project.com/
For database:
Bugs:
1) Description: Recommendations don’t work
Environment: LOCAL
Steps to reproduce:
- Start the whole application with the script;
- Open the browser;
- Navigate to the application home page;
- If logged in – log out;
Expected result: list of recommended songs, albums, artists is displayed;
Actual result: nothing is displayed;
Visual proof:
Figure 1. Bug 1 visual proof.
2) Description: login attempt lasts forever
Environment: LOCAL
Steps to reproduce:
- Start the whole application with the script;
- Open the browser;
- Navigate to the application home page;
- Click the ‘Log in’ button on the navigation bar;
- Enter ‘username’ input;
- Enter ‘password’ input;
- Click the ‘Log in’ button below to confirm the action;
Expected result:
- After some meaningful period of time the user is either logged in or not based on the input;
- The user receives message indicating the status of the operation and the button is styled accordingly.
Figure 2. Expected result of failed log in attempt
Actual result: loading indicator hangs on and the user is not logged in;
Visual proof:
Figure 3. Bug 2 visual proof.
3) Description: the artist is searchable and can be navigated, but it’s profile and information is not loaded or doesn’t exist
Environment: LOCAL
Steps to reproduce:
- Start the whole application with the script;
- Open the browser;
- Navigate to the application home page;
- In the ‘Search’ field on the navigation bar start entering some artist (the bug was noticed on ‘Daftside’ input);
- Click the corresponding search result hint popup to navigate to the profile page.
Expected result:
- The user successfully navigates to the selected artist’s profile page.
- All the information is populated and visible: the profile image, description and bio, albums, songs, ratings and comments section, events tab etc.
Figure 4. Expected result example.
Actual result: the profile page is successfully navigated and loaded, but no information is filled/displayed.
Visual proof:
Figure 5. Bug 3 visual proof.
The
Problem Domain Tree
Problem domain component
Project bugs description
Project component diagram
Conclusion:
the following components are reusable: MusicSocialNetwork-WebApp, Common,
CatalogService, MusicService, UserService. There is no need to reuse
EventService, RecommenderService, TicketingService, as long as their
functionality is not required for our problem domain.
Domain repository table
Requirements specification for the software system
Conclusion about possibility to reuse of software components from our working project to design a new similar systems.
I can say that all my components can be reused.
The conclusion can be made from the domain repository tree . Thus, a lot of components from the working project can be used in the development of new systems. Components cover a large part of the necessary functionality. Some of them require further modifications, but do not require cardinal changes.
But unfortunately there are not enough components such as ordering service, basket service, discounts service, etc. That naturally complicates the work of the platform and makes it not full-fledged to use.
How possible reuse will influent for possible reuse risks.
I believe that before using components to make sure there are no risks in the architecture. Because if some minimal functionality such as "delete a song from the collection" can be added without any problems, the introduction of major functionality such as ordering service, basket service, discounts service, etc. can be problematic because the components of the program interconnected differently and they would not have foreseen such functionality.
