SWD
SWD
<Position>
<Position>
<Position>
<Position>
TABLE OF CONTENTS
Record of change
TABLE OF CONTENTS
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview
2. Architectural Representation
2.1. Notations and Standards
2.2. Architectural Views
2.3. Modeling Tools
2.4. Overview of Diagrams
2.5. Assumptions
3. Architectural Goals and Constraints
3.1. Architectural Goals
3.2. Architectural Constraints
3.3. Design and Implementation Strategy
4. Use-Case View
4.1. Key Use Cases
4.1.1. Overview:
4.1.2. List of Use Cases:
4.2. Use-Case Description Format
4.3. Architectural Coverage
4.4. Visual Representation (Optional)
5. Logical View
5.1. Overview
5.2. Architecturally Significant Design Packages
5.2.1. Package: UserManagement
6. Process View
7. Deployment View
8. Implementation View
8.1. Overview
8.2. Layers
9. Data View (optional)
10. Size and Performance
11. Quality
12. Other Considerations
1. Introduction
This document provides the system architecture and design details for the Smartphone Online Shop
System (SOSS), which is aimed at managing the lifecycle of customer orders, including product selection,
order placement, payment processing, and order tracking. It serves as a reference for all project
stakeholders.
1.1 Purpose
The SOSS is designed to simplify the process of managing customer orders for an online store. It
provides features such as inventory management, payment integration, and real-time order tracking. This
document acts as a blueprint to guide developers and ensures that the system adheres to specified
business and technical requirements.
1.2 Scope
The SOSS covers the core functionalities required for order management in an online retail platform.
In Scope:
Out of Scope:
Intended Audience:
This section defines terms used throughout the document to avoid ambiguity.
RESTful
1.4 References
1.5 Overview
Section 3: Architectural Goals and Constraints - Outlines the guiding principles and system limitations.
Section 4: Use-Case View - Describes how end-users interact with the system.
Section 5: Logical View - Provides an overview of the system's main components and their relationships.
Section 6: Process View - Explains the system's internal processes and workflows.
Section 7: Deployment View - Illustrates the physical deployment of the system across servers.
Section 8: Implementation View - Discusses coding standards, layers, and technologies used.
Section 9: Data View - Optional details about the database design and schemas.
Section 10-12: Covers system performance, quality attributes, and other considerations.
2. Architectural Representation
● Logical View: Represents the static structure of the system, such as key components and their
relationships.
● Process View: Focuses on runtime aspects, such as communication between components,
concurrency, and data flow.
● Deployment View: Shows how the system will be physically deployed on hardware
infrastructure.
● Use-Case View: Demonstrates key scenarios and their interaction with system components.
The diagrams and artifacts in this document were created using Lucidchart and follow standard UML
notations. Visual Paradigm is used for collaborative modeling and ensuring consistency across
architectural views.
The following types of diagrams are used to describe the system architecture:
2.5. Assumptions
The architectural models in this document focus on the high-level design of the system and do not
include implementation-specific details, such as specific programming constructs or optimization
strategies.
3. Architectural Goals and Constraints
[This section lists use cases or scenarios from the use-case model if they represent some significant,
central functionality of the final system, or if they have a large architectural coverage - they exercise
many architectural elements, or if they stress or illustrate a specific, delicate point of the architecture.]
4.1.1. Overview:
Explain the criteria for selecting the key use cases.
Main Flow: 1. The guest navigates to the "Register" page or selects the "Register" option
2. The guest fills out the registration form with the required information:
3. The guest submits the registration form.
4. The system validates the information.
5. The system sends a verification email to the provided email address
6. The guest checks their email or phone and clicks the verification link or
enters the verification code.
7. The system confirms the verification and creates the user account.
8. The system logs the user in automatically and redirects them to the
homepage.
Related Use Cases: UC: Provide Personal information, UC: Create Login Credentials, UC: Verify
Email address
Sequence Diagram
Screen Wireframes
_Use Case ID Provide personal information
Main Flow: 1. The guest navigates to the "Register" page or selects the "Register" option
2. The guest fills out the registration form with the required information:
Full name
Email address or phone number
Password (and confirmation)
3. The guest submits the registration form.
Sequence Diagram
Screen Wireframes
Preconditions: 1. The guest has provided their personal information (e.g., name, email,
phone number) during the registration process.
2. The system has validated the provided information.
Main Flow: 1. The guest is prompted to create login credentials (username and password)
after providing personal information.
2. The guest enters a username (if required) and a password.
3. The guest confirms the password by entering it again.
4. The system validates the login credentials and is ready to proceed.
Triggers - The guest has successfully provided their personal information and is
prompted to create login credentials.
Frequency of Use Major
Related Use Cases: UC: Provide Personal information, UC: Register into System, UC: Verify Email
address
Sequence Diagram
Screen Wireframes
Description As a guest , I want the system verifies the email address provided to ensure it
is valid and belongs to me.
Preconditions: 1. The guest has provided their email address during the registration process.
2. The system has validated the email format and ensured it is not already
registered.
2. The guest’s account is logged into the database, and they are logged into
the system.
Main Flow: 1. The system generates a unique verification link or code and sends it to the
guest’s provided email address.
2. The guest checks their email inbox and opens the verification email.
3. The guest clicks the verification link or enters the verification code on the
registration page.
4. The system validates the verification link or code
5. The system confirms the email address as verified and log the info into
database.
6. The system logs the guest in automatically and redirects them to the
homepage
Triggers - The guest submits their email address during the registration process,
and the system initiates the verification process.
Related Use Cases: UC: Register into system , UC: Create Login Credentials, UC: Provide Personal
Information
Sequence Diagram
Screen Wireframes
Description As the guest or user, I want to view detailed information about a specific
smartphone, including its specifications, images, price, reviews
2. The guest or user has navigated to the product listing page or search
results.
Main Flow: 1. The guest or user selects a product from the product listing page or search
results.
2. The system retrieves the product details from the database.
3. The system displays the product details page.
Triggers - The guest or user clicks on a product from the product listing page,
search results, or a promotional banner.
Sequence Diagram
Screen Wireframes
Postconditions: 1. The guest or user has viewed a list of products that match their search
criteria.
2. The products remains accessible for further interaction.
Triggers - The guest or user enters a search term in the search bar or use filter
result and clicks the "Search" button.
Business Rules - When the system can’t find any product, it must reports back to the
guest/user.
Related Use Cases: UC: Search Product By Price, UC: Search Product By Name, UC: Search
Product By Brand.
Sequence Diagram
Screen Wireframes
_Use Case ID Search Product By Price
Description As guest or user, I want to search for smartphones within a specific price
range by applying a price filter. The system displays a list of products that fall
within the specified price range.
Preconditions: 1. The guest or user is on the product listing page, search results page, or a
category page.
2. The price filter functionality is available and accessible.
Postconditions: 1. The guest or user has viewed a list of products that fall within the specified
price range
Main Flow: 1. The guest or user selects the "Price Filter" option on the product listing
page or search results page
2. The guest or user applies the price filter.
3. The system retrieves products that fall within the specified price range from
the database.
4. The system displays a list of matching products
Triggers - The guest or user selects the "Price Filter" option and applies a price
range to the product list.
Business Rules - When the system can’t find any product, it must reports back to the
guest/user.
Related Use Cases: UC: Search Product , UC: Search Product By Name, UC: Search Product By
Brand.
Sequence Diagram
Screen Wireframes
Preconditions: 1. The guest or user is on the product listing page, or search results page.
2. The search functionality is available and accessible.
Postconditions: 1. The guest or user has viewed a list of products that match the search term.
Main Flow: 1. The guest or user enters a product name or keyword into the search bar.
2. The guest or user clicks the "Search" button or presses "Enter."
3. The system retrieves products that match the search term from the
database.
4. The system displays a list of matching products
Triggers - The guest or user enters a product name or keyword in the search bar
and clicks the "Search" button or presses "Enter."
Frequency of Use Medium
Business Rules - When the system can’t find any product, it must reports back to the
guest/user.
Related Use Cases: UC: Search Product , UC: Search Product By Price, UC: Search Product By
Brand.
Sequence Diagram
Screen Wireframes
Preconditions: 1. The guest or user is on the product listing page, or search results page.
2. The brand filter functionality is available and accessible.
Postconditions: 1. The guest or user has viewed a list of products that belong to the selected
brand.
Main Flow: 1. The guest or user selects the "Brand Filter" option on the product listing
page or search results page
2. The guest or user selects a specific brand from the list of available brands.
3. The system retrieves products that belong to the selected brand from the
database.
4. The system displays a list of matching products
Alternative Flows N/A
Triggers - The guest or user selects the "Brand Filter" option and chooses a
specific brand from the list.
Business Rules - When the system can’t find any product, it must reports back to the
guest/user.
Related Use Cases: UC: Search Product , UC: Search Product By Price, UC: Search Product By
Brand.
Sequence Diagram
Screen Wireframes
Triggers - The user navigates to the "Profile" section to view or selects an option
to update their profile information.
Sequence Diagram
Screen Wireframes
Description The registered user can update their account password by providing their
current password and entering a new password. The system validates the new
password and updates it securely.
Main Flow: 1. The user navigates to the "Change Password" section in their Profile
settings.
2. The user enters their current password.
3. The user enters a new password and confirms it by re-entering it.
4. The system validates the new password.
5. The system verifies that the current password is correct.
6. The system updates the user’s password securely in the database.
7. The system confirms that the password has been changed successfully.
Triggers - The user navigates to the "Change Password" section in their Profile
settings.
Sequence Diagram
Screen Wireframes
Main Flow: 1. Manager Clicks the button “Report” in the header bar
2. System displays list of problem reports
3. Manager reviews report details
4. Manager gives appropriate actions
Sequence Diagram
Screen Wireframes
Description As a managers, I want to search and filter order problem reports using
various criteria to quickly locate specific reports.
Sequence Diagram
Screen Wireframes
Sequence Diagram
Screen Wireframes
Description As a managers, I want to search and filter order problem reports by date
Sequence Diagram
Screen Wireframes
a. Architectural Coverage
● Highlight how these use cases span various system components, focusing on architectural
significance.
[This section describes the architecturally significant parts of the design model, such as its decomposition
into subsystems and packages. And for each significant package, its decomposition into classes and class
utilities. You should introduce architecturally significant classes and describe their responsibilities, as well
as a few very important relationships, operations, and attributes.]
a. Overview
The system is divided into three primary layers:
1. Presentation Layer: Manages user interfaces and interactions with the system.
○ LoginController, ProductPage.
2. Business Logic Layer: Contains the core application logic, including order processing and user
management.
○ OrderService, UserManager.
3. Data Access Layer: Manages data persistence and communication with the database.
○ OrderRepository, ProductRepository.
This architecture allows for separation of concerns, making the system more maintainable and scalable.
Description: Handles all user-related operations, including registration, authentication, and profile
updates.
Diagram:
Below is a class diagram representing the UserManagement package:
+------------------+ +-------------------+
| Order |<-------->| OrderService |
+------------------+ +-------------------+
| orderId | | processOrder() |
| orderDate | | cancelOrder() |
+------------------+ +-------------------+
|
V
+-----------------------+
| OrderRepository |
+-----------------------+
| saveOrder() |
| getOrderById() |
+-----------------------+
Classes
User Represents the Store user userId, None directly (basic data
user entity with information. userName, email object).
personal details.
5. PROCESS VIEW
[This section describes the system's decomposition into lightweight processes (single threads of
control) and heavyweight processes (groupings of lightweight processes). Organize the section by
groups of processes that communicate or interact. Describe the main modes of communication
between processes, such as message passing, interrupts, and rendezvous.]
6. DEPLOYMENT VIEW
[This section describes one or more physical network (hardware) configurations on which the
software is deployed and run. At a minimum for each configuration it should indicate the physical
nodes (computers, CPUs) that execute the software, and their interconnections (bus, LAN, point-to-
point, and so on.) Also include a mapping of the processes of the Process View onto the physical
nodes.]
7.Implementation View
[This section describes the overall structure of the implementation model, the decomposition of the
software into layers and subsystems in the implementation model, and any architecturally
significant components.]
a. Overview
[This subsection names and defines the various layers and their contents, the rules that govern the
inclusion to a given layer, and the boundaries between layers. Include a component diagram that
shows the relations between layers. ]
b. Layers
[For each layer, include a subsection with its name, an enumeration of the subsystems located in
the layer, and a component diagram.]
10. Quality
[A description of how the software architecture contributes to all capabilities (other than
functionality) of the system: extensibility, reliability, portability, and so on. If these characteristics
have special significance, for example safety, security or privacy implications, they should be clearly
delineated.]
11. Other Considerations
[This section provides a description of other approaches/ solutions that were considered in
selection process for the above architecture, i.e. a brief explanation of advantages and
disadvantages of the selected architecture in comparison with others. It should be a clear answer
to the question why the above architecture is selected for this system, not the others.]