0% found this document useful (0 votes)
2 views

SWD

The document outlines the software architecture for the Smartphone Online Shop System (SOSS), detailing its purpose, scope, and architectural representation. It includes sections on architectural goals, use-case views, and various architectural diagrams, providing a comprehensive guide for developers and stakeholders. The SOSS aims to streamline customer order management with features like inventory management and payment integration.

Uploaded by

Long Đoàn
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views

SWD

The document outlines the software architecture for the Smartphone Online Shop System (SOSS), detailing its purpose, scope, and architectural representation. It includes sections on architectural goals, use-case views, and various architectural diagrams, providing a comprehensive guide for developers and stakeholders. The SOSS aims to streamline customer order management with features like inventory management and payment integration.

Uploaded by

Long Đoàn
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 33

<LOGO>

<Name of the project>


Software Architecture

Project Code: <Code of the project>

Document Code: <Code of the document >– v<x.x>

<Location, issued date of the Document>


Record of change

*A - Added M - Modified D - Deleted


Effective Date Changed Items A*,M, D Change Description New Version
SIGNATURE PAGE

ORIGINATOR: <Name> <Date>

<Position>

REVIEWERS: <Name> <Date>

<Position>

<Name, if it’s needed> <Date>

<Position>

APPROVAL: <Name> <Date>

<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:

● Product catalog management.


● Shopping cart functionality.
● Order confirmation and tracking notifications.
● Customer profile and order history management.

Out of Scope:

● Inventory replenishment automation.


● //Advanced analytics and machine learning integration.

Intended Audience:

● Developers working on the SOSS platform.


● QA engineers testing system functionalities.
● Business analysts defining feature requirements.
1.3 Definitions, Acronyms, and Abbreviations

This section defines terms used throughout the document to avoid ambiguity.

API Application Programming Interface - Used for system-to-system communication.

UX/UI User Experience/User Interface.

RESTful

1.4 References

This document references the following resources and standards:

● "Architectural Patterns: Principles and Practices" by Mark Richards.


● REST API Design Best Practices (Version 2.0).
● Payment Gateway Integration Guide: Stripe API v2023-01.
● Internal E-Commerce Requirements Document v1.3.

1.5 Overview

This document is structured into the following sections:

Section 2: Architectural Representation - Details the system's high-level structure.

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

2.1. Notations and Standards


The architecture is represented using UML 2.5 diagrams, including use-case diagrams, sequence
diagrams, class diagrams, and deployment diagrams. These diagrams follow the Unified Modeling
Language (UML) standard and provide a clear representation of both structural and behavioral aspects of
the system.

2.2. Architectural Views

The architecture is described using the following views:

● 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.

2.3. Modeling Tools

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.

2.4. Overview of Diagrams

The following types of diagrams are used to describe the system architecture:

● Use-Case Diagrams: Describe system functionalities from an end-user perspective.


● Class Diagrams: Depict the static structure of the system, including classes and their
relationships.
● Sequence Diagrams: Show interactions between components over time to fulfill a use case.
● Deployment Diagrams: Illustrate how software components are mapped to the underlying
hardware infrastructure."

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

3.1. Architectural Goals


The architectural goals for the Smartphone Online Shop System (SOSS) are:
● Scalability: Ensure the system can handle up to 10,000 concurrent users without performance
degradation.
● Maintainability: The architecture should allow for easy updates to components such as product
catalogs and user management.
● Security: Protect sensitive user data, including payment information and personal details, using
robust encryption and access control mechanisms.
● Portability: The system should run on both cloud-based and on-premise environments.
● Reusability: Core modules, such as user authentication, should be designed for reuse in future
projects.

3.2. Architectural Constraints


● Technical Constraints:
○ The system must be implemented using Java Spring Boot to align with the organization’s
technology stack.
○ MySQL is mandated as the database management system due to prior investments in
this technology.
○ APIs must adhere to RESTful principles.
● Organizational Constraints:
○ The development team consists of five members, requiring the architecture to support
modular development to divide work efficiently.
● External Constraints:
○ Integration with a third-party gateway (e.g., Google).

3.3. Design and Implementation Strategy


The architecture will follow a microservices-based approach, ensuring independent development and
deployment of components. The development process will adhere to Agile principles with two-week
sprints, enabling iterative delivery. Development tools include IntelliJ IDEA for backend development, and
Docker for containerization.
4. Use-Case View

[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.]

Introduction:Provide a brief introduction to the purpose of the Use-Case View.

4.1. Key Use Cases

4.1.1. Overview:
Explain the criteria for selecting the key use cases.

4.1.2. List of Use Cases:


● Use Case 1: Browse Products

4.2. Use-Case Description Format


_Use Case ID Register into System

Description As a guest , I want to to create an account by providing required information


such as email, password, name, and phone number. Upon successful
registration, the I can log in and interact with the system.

Primary Actor: Guest


Actors
Secondary Actors

Preconditions: 1. The guest is not logged into the system.


2. The guest has access to a valid email address or phone number for
verification.
3. The registration feature is available and accessible.

Postconditions: 1. The guest is now a registered user.


2. The user’s account is created and stored in the system.
3. A verify email is sent to the provided email address.
4. Gaining access to system features.

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.

Alternative Flows N/A

Exceptions Exception 1: Database Error


- The system encounters a database error while saving the guest’s
registration information
Exception 2: Network Connection Lost
- The guest loses their internet connection during the registration
process.
Exception 3: Invalid Verification Link/Code
- The guest clicks an expired or invalid verification link or enters an
incorrect verification code.
Exception 4: Invalid Format
- The guest enters info that does not match the required format.
Exception 5: Duplicate Email
- The guest enters an email address that is already registered in the
system.
Exception 6: Verification Email
- The system fails to send the verification email (e.g., due to a server
error or invalid email).

Triggers - The guest navigates to the "Register" page by clicking a "Register"


or "Sign Up" button on the homepage
- Alternatively, the guest may be prompted to register when attempting
to perform an action that requires an account

Frequency of Use Major

Business Rules 1.Username, password not be empty


2.Username not allow special character and max 16 characters
3.Password min 8 characters

Related Use Cases: UC: Provide Personal information, UC: Create Login Credentials, UC: Verify
Email address

Diagrams Use-Case Diagram

Sequence Diagram

Screen Wireframes
_Use Case ID Provide personal information

Description As a guest , I want to create an account by providing required information


such as email, password, name, and phone number. Upon successful
registration, the I can log in and interact with the system.

Primary Actor: Guest


Actors
Secondary Actors

Preconditions: 1. The guest is on the registration page or prompted to provide personal


information.
2. The registration feature is available and accessible.

Postconditions: 1. The guest has successfully provided their personal information.


2. The system has validated the information and is ready to proceed.

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.

Alternative Flows N/A

Exceptions Exception 1: Database Error


- The system encounters a database error while saving the guest’s
registration information
Exception 2: Network Connection Lost
- The guest loses their internet connection during the registration
process.
Exception 3: Invalid Format
- The guest enters info that does not match the required format.
Exception 4: Duplicate Email
- The guest enters an email address that is already registered in the
system.

Triggers - The guest navigates to the "Register" page by clicking a "Register"


or "Sign Up" button on the homepage
- Alternatively, the guest may be prompted to register when attempting
to perform an action that requires an account

Frequency of Use Major

Business Rules 1.Username, password not be empty


2.Username not allow special character and max 16 characters
3.Password min 8 characters
Related Use Cases: UC: Register into system , UC: Create Login Credentials, UC: Verify Email
address

Diagrams Use-Case Diagram

Sequence Diagram

Screen Wireframes

_Use Case ID Create Login Credentials

Description As a guest, I want to creates a username and password to secure my account


and enable future logins.

Primary Actor: Guest


Actors
Secondary Actors

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.

Postconditions: 1. The guest is now a registered user.


2. The user’s account is created and stored in the system.
3. A verify email is sent to the provided email address.
4. Gaining access to system features.

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.

Alternative Flows N/A

Exceptions Exception 1: Database Error


- The system encounters a database error while saving the guest’s
registration information
Exception 2: Network Connection Lost
- The guest loses their internet connection during the registration
process.
Exception 3: Invalid Format
- The guest enters info that does not match the required format.

Triggers - The guest has successfully provided their personal information and is
prompted to create login credentials.
Frequency of Use Major

Business Rules 1.Username, password not be empty


2.Username not allow special character and max 16 characters
3.Password min 8 characters

Related Use Cases: UC: Provide Personal information, UC: Register into System, UC: Verify Email
address

Diagrams Use-Case Diagram

Sequence Diagram

Screen Wireframes

_Use Case ID Verify Email address

Description As a guest , I want the system verifies the email address provided to ensure it
is valid and belongs to me.

Primary Actor: Guest


Actors
Secondary Actors

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.

Postconditions: 1. The guest’s email address has been successfully verified.

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

Alternative Flows N/A

Exceptions Exception 1: Database Error


- The system encounters a database error while saving the guest’s
registration information
Exception 2: Network Connection Lost
- The guest loses their internet connection during the registration
process.
Exception 3: Invalid Verification Link/Code
- The guest clicks an expired or invalid verification link or enters an
incorrect verification code.
Exception 4: Verification Email
- The system fails to send the verification email (e.g., due to a server
error or invalid email).

Triggers - The guest submits their email address during the registration process,
and the system initiates the verification process.

Frequency of Use Major

Business Rules 1. Email must be in the right format

Related Use Cases: UC: Register into system , UC: Create Login Credentials, UC: Provide Personal
Information

Diagrams Use-Case Diagram

Sequence Diagram

Screen Wireframes

_Use Case ID View Product

Description As the guest or user, I want to view detailed information about a specific
smartphone, including its specifications, images, price, reviews

Actors Primary Actor: Guest, User


Secondary Actors: N/A

Preconditions: 1. The product exists in the system.

2. The guest or user has navigated to the product listing page or search
results.

Postconditions: 1. The guest or user has successfully viewed the product.


2. The product remains accessible for further interaction.

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.

Alternative Flows N/A

Exceptions Exception 1: Database Error


- The system encounters a database error while retrieve the product
Exception 2: Network Connection Lost
- The guest or user loses their internet connection while viewing the
product

Triggers - The guest or user clicks on a product from the product listing page,
search results, or a promotional banner.

Frequency of Use High

Business Rules N/A

Related Use Cases: N/A

Diagrams Use-Case Diagram

Sequence Diagram

Screen Wireframes

_Use Case ID Search Product


Description As guest or user, I want to search for smartphones by entering keywords,
applying filters, or using advanced search options. The system displays a list
of products that match the search criteria.

Primary Actor: Guest, User


Actors
Secondary Actors: N/A

Preconditions: 1. The product exists in the system.

2. The guest or user is on the product listing page.


3. The search functionality is available and accessible.

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.

Main Flow: 1. The guest or user enters their search criteria.


2. The system retrieves products that match
3. The system displays a list of matching products

Alternative Flows Alternative Flows 1: Search Product with filters


- The guest or user applies filters to narrow down the search results.
- The system updates the search results based on the applied filters.

Exceptions Exception 1: Database Error


- The system encounters a database error while retrieve the product
Exception 2: Network Connection Lost
- The guest or user loses their internet connection while searching for
products

Triggers - The guest or user enters a search term in the search bar or use filter
result and clicks the "Search" button.

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 By Price, UC: Search Product By Name, UC: Search
Product By Brand.

Diagrams Use-Case Diagram

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.

Primary Actor: Guest, User


Actors
Secondary Actors: N/A

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

Alternative Flows N/A

Exceptions Exception 1: Database Error


- The system encounters a database error while retrieve the product
Exception 2: Network Connection Lost
- The guest or user loses their internet connection while searching for
products

Triggers - The guest or user selects the "Price Filter" option and applies a price
range to the product list.

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 Name, UC: Search Product By
Brand.

Diagrams Use-Case Diagram

Sequence Diagram

Screen Wireframes

_Use Case ID Search Product By Name

Description As guest or user, I want to search for smartphones by entering a specific


product name or keyword. The system displays a list of products that match
the search term.

Primary Actor: Guest, User


Actors
Secondary Actors: N/A

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

Alternative Flows N/A

Exceptions Exception 1: Database Error


- The system encounters a database error while retrieve the product
Exception 2: Network Connection Lost
- The guest or user loses their internet connection while searching for
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.

Diagrams Use-Case Diagram

Sequence Diagram

Screen Wireframes

_Use Case ID Search Product By Brand

Description As guest or user, I want to search for smartphones by selecting a specific


brand from a list of available brands. The system displays a list of products
that belong to the selected brand.

Primary Actor: Guest, User


Actors
Secondary Actors: N/A

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

Exceptions Exception 1: Database Error


- The system encounters a database error while retrieve the product
Exception 2: Network Connection Lost
- The guest or user loses their internet connection while searching for
products

Triggers - The guest or user selects the "Brand Filter" option and chooses a
specific brand from the list.

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.

Diagrams Use-Case Diagram

Sequence Diagram

Screen Wireframes

_Use Case ID Manage Profile

Description As aregistered user, I want to update and manage my profile information,


personal details.

Primary Actor: User


Actors
Secondary Actors: N/A

Preconditions: 1. The user is logged into their account.


2. The profile management feature is available and accessible.

Postconditions: 1. The user’s profile information has been successfully updated.


2. The system has securely stored the updated information.
3. The user can continue using the system with their updated profile.

Main Flow: 1. The user navigates to the "Profile" section.


2. The user selects an option to update or view their profile information
3. The user enters the new information.
4. The user press “Save”.
5. The system saves the updated information securely in the database.
6. The system confirms that the profile has been updated successfully.

Alternative Flows N/A

Exceptions Exception 1: Database Error


- The system cannot save the updated information due to a database
error
Exception 2: Network Connection Lost
- The user loses their internet connection while updating their profile

Triggers - The user navigates to the "Profile" section to view or selects an option
to update their profile information.

Frequency of Use Medium

Business Rules -First name must not empty


-Last name must not empty
-Gender must not empty
-Phone number must not empty, start begin 0, at least 9 digits
-Address must not empty

Related Use Cases: N/A

Diagrams Use-Case Diagram

Sequence Diagram

Screen Wireframes

_Use Case ID Change Password

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.

Primary Actor: User


Actors
Secondary Actors: N/A

Preconditions: 1. The user is logged into their account.


2. The "Change Password" feature is available and accessible.
Postconditions: 1. The user’s password has been successfully updated.
2. The system has securely stored the new password.
3. The user can log in with the new password.

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.

Alternative Flows N/A

Exceptions Exception 1: Database Error


- The system cannot update the password due to a database error
Exception 2: Network Connection Lost
- The user loses their internet connection during the password change
process

Triggers - The user navigates to the "Change Password" section in their Profile
settings.

Frequency of Use Medium

Business Rules 1.Password min 8 characters.


2.Confirm password must match new password.

Related Use Cases: N/A

Diagrams Use-Case Diagram

Sequence Diagram

Screen Wireframes

_Use Case ID Manage Report

Description As a managers, I want to reviews and processes user-submitted order


problem reports to ensure timely resolution and customer satisfaction.
Primary Actor: Manager
Actors
Secondary Actors: N/A

Preconditions: 1. The user is logged into their account.


2. Manager is authenticated in the system
3. Reports exist in the system

Postconditions: 1. Reports are reviewed.


2. Appropriate actions are taken.

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

Alternative Flows N/A

Exceptions Exception 1: Database Error


- System unable to load or update reports
Exception 2: Network Connection Lost
- Manager lost connection while access reports

Triggers - Manager Clicks the button “Report” in the header bar

Frequency of Use Medium

Business Rules N/A

Related Use Cases: N/A

Diagrams Use-Case Diagram

Sequence Diagram

Screen Wireframes

_Use Case ID Search Report

Description As a managers, I want to search and filter order problem reports using
various criteria to quickly locate specific reports.

Primary Actor: Manager


Actors
Secondary Actors: N/A

Preconditions: 1. The user is logged into their account.


2. Manager is authenticated in the system
3. Reports exist in the system
4. "Search Report" feature is available and accessible.

Postconditions: 1. Matching reports are retrieved.


2. Search results are displayed.
3. Manager can access detailed report information

Main Flow: 1. Manager uses search functionality


2. Manager selects search criteria
3. System displays matching reports
4. Manager views detailed report information

Alternative Flows N/A

Exceptions Exception 1: Database Error


- System unable to search reports due to database error.
Exception 2: Network Connection Lost
- Manager lost connection while searching reports.

Triggers - Manager Clicks the button “Search” in the Report section

Frequency of Use Medium

Business Rules N/A

Related Use Cases: N/A

Diagrams Use-Case Diagram

Sequence Diagram

Screen Wireframes

_Use Case ID Search Report by username

Description As a managers, I want to search reports by username

Primary Actor: Manager


Actors
Secondary Actors: N/A

Preconditions: 1. The user is logged into their account.


2. Manager is authenticated in the system
3. Reports exist in the system
4. "Search Report" feature is available and accessible.

Postconditions: 1. Matching reports are retrieved by username.


2. Search results are displayed.
3. Manager can access detailed report information

Main Flow: 1. Manager uses search functionality


2. Manager enter username into search bar
3. System displays matching reports
4. Manager views detailed report information

Alternative Flows N/A

Exceptions Exception 1: Database Error


- System unable to search reports due to database error.
Exception 2: Network Connection Lost
- Manager lost connection while searching reports.

Triggers - Manager Clicks the button “Search” in the Report section

Frequency of Use Medium

Business Rules N/A

Related Use Cases: N/A

Diagrams Use-Case Diagram

Sequence Diagram

Screen Wireframes

_Use Case ID Search Report by Date

Description As a managers, I want to search and filter order problem reports by date

Primary Actor: Manager


Actors
Secondary Actors: N/A

Preconditions: 1. The user is logged into their account.


2. Manager is authenticated in the system
3. Reports exist in the system
4. "Search Report" feature is available and accessible.

Postconditions: 1. Matching reports are retrieved by date.


2. Search results are displayed.
3. Manager can access detailed report information

Main Flow: 1. Manager uses search functionality


2. Manager selects search date criteria
3. System displays matching reports
4. Manager views detailed report information

Alternative Flows N/A

Exceptions Exception 1: Database Error


- System unable to search reports due to database error.
Exception 2: Network Connection Lost
- Manager lost connection while searching reports.

Triggers - Manager Clicks the button “Search” in the Report section

Frequency of Use Medium

Business Rules N/A

Related Use Cases: N/A

Diagrams Use-Case Diagram

Sequence Diagram

Screen Wireframes

a. Architectural Coverage
● Highlight how these use cases span various system components, focusing on architectural
significance.

b. Visual Representation (Optional)


A high-level use-case diagram showing relationships between actors and use cases.
4.Logical View

[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.

b. Architecturally Significant Design Packages


i. Package: UserManagement

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

Class Name Description Responsibilities Key Attributes Key Operations

User Represents the Store user userId, None directly (basic data
user entity with information. userName, email object).
personal details.

AuthenticationS Provides Authenticate users, None authenticateUser(userNam


ervice functionality for reset passwords, e, password)
authenticating manage sessions. resetPassword(email)
and managing
user access.

UserRepository Handles data Save user details to None saveUser(User user)


persistence for the database, retrieve getUserById(userId)
user entities. by ID.

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.]

8.Data View (optional)


[A description of the persistent data storage perspective of the system. This section is optional if
there is little or no persistent data, or the translation between the Design Model and the Data
Model is trivial.]

9.Size and Performance


[A description of the major dimensioning characteristics of the software that impact the
architecture, as well as the target performance constraints.]

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.]

You might also like