4.1. Create system design document.

Framework Configuration Record for Electronic and Apparatus Retail location Site

1. Presentation:
The motivation behind this Framework Configuration Report (SDD) is to give a complete outline
of the electronic and machine retail location site. This archive frames the significant level design,
parts, points of interaction, and conduct of the framework. It fills in as an aide for designers,
analyzers, and partners to grasp the framework's construction, usefulness, and execution.

2. Extension and Goals:

Primary Highlights and Works:
Item Index: Show definite item data, pictures, and costs.
Client Records: Empower client enrollment, login, and profile the board.
Shopping basket: Permit clients to add/eliminate things, view truck, and continue to checkout.
Installment Passage Mix: Safely process installments utilizing well known techniques.
Request The board: Track orders, update request status, and give transporting subtleties.
Search and Channels: Carry out a hearty hunt usefulness and item channels.
Client Surveys and Evaluations: Permit clients to rate and audit items.
Administrator Board: Oversee items, orders, client information, and site content.
Safety efforts: Carry out SSL encryption, secure client information capacity, and safeguard
against web weaknesses.

Target Clients and Clients:

End Clients: People looking to buy electronic apparatuses on the web.
Chairmen: Head supervisors and staff answerable for site the board.
Non-Practical Necessities:

Execution: Quick page stacking, considerably under weighty traffic.

Versatility: Capacity to deal with expanded client and item information base burdens.
Security: Secure client verification, information encryption, and installment handling.
Dependability: Limited personal time, predictable information, and standard reinforcements.
3. Framework Parts and Communications:
Frontend: UI, item pages, shopping basket, and client account the board.
Backend: Server, application rationale, data set, and outside help combinations.
Data set: Store item subtleties, client information, request data, and audits.
Outside Frameworks: Installment entryways, stock administration frameworks, and delivery
administrations.
Outlines:
Use Case Outline: Represents client framework cooperation.
UML Class Outline: Addresses classes and connections in the framework.
Information Stream Outline: Shows information development among parts and outer
frameworks.

4. Framework Points of interaction and APIs:

Peaceful APIs: Characterize endpoints for validation, item the executives, and request handling.
Information Configurations: Use JSON for information trade between frontend, backend, and
outside administrations.
Confirmation: Carry out OAuth or JWT tokens for secure Programming interface access.
Installment Entryway Programming interface: Coordinate with a solid installment supplier's
Programming interface for exchanges.
Instruments:
Strut: Archive APIs, input/yield designs, and produce code bits.

5. Framework Conduct and Rationale:

Use Cases: Characterize situations like client enlistment, item search, checkout, and request
following.
Flowcharts: Picture process streams, choices, and information development.
Pseudocode: Give itemized rationale to basic calculations like installment handling.

6. Assessment and Approval:

Execution Testing: Recreate weighty client loads utilizing instruments like Apache JMeter.
Prototyping: Foster intelligent models for client input and connection point approval.
Security Testing: Direct weakness evaluations and infiltration testing.
Client Acknowledgment Testing (UAT): Connect genuine clients for testing and criticism.
Contemplations:
Compromises: Equilibrium execution, usefulness, and security in light of assets and limitations.
Restrictions: Report imperatives in innovation, financial plan, or course of events influencing
framework plan.
This Framework Configuration Report gives a point-by-point guide to the improvement of the
electronic and machine retail location site. By following the illustrated engineering, connection
points, and conduct, the framework plans to meet the characterized targets and necessities.
Ordinary assessment, testing, and refinement will guarantee the framework's outcome in
conveying a consistent and secure web-based shopping experience for clients and overseers the
same.
Start
|
|----- Define Scope and Objectives -----|
| |
| |----- Identify Main Features and Functions ------|
| | |
| | |----- Product Catalog? -----|
| | |
| | |----- User Accounts? -----|
| | |
| | |----- Shopping Cart? -----|
| | |
| | |----- Payment Gateway Integration? -----|
| | |
| | |----- Order Management? -----|
| | |
| | |----- Search and Filters? -----|
| | |
| | |----- User Reviews and Ratings? -----|
| | |
| | |----- Admin Panel? -----|
| | |
| | |----- Security Measures? -----|
| |
| |----- Define Target Users and Customers ------|
| | |
| | |----- End Users? -----|
| | |
| | |----- Administrators? -----|
| |
| |----- Define Non-Functional Requirements ------|
| | |
| | |----- Performance? -----|
| | |
| | |----- Scalability? -----|
| | |
| | |----- Security? -----|
| | |
| | |----- Reliability? -----|
| |
|
|----- Identify System Components and Interactions -----|
| |
| |----- Frontend -----|
| | |
| | |----- Backend -----|
| | |
| | |----- Database -----|
| | |
| | |----- External Systems -----|
| |
|
|----- Specify System Interfaces and APIs -----|
| |
| |----- RESTful APIs -----|
| | |
| |----- Data Formats -----|
| | |
| |----- Authentication -----|
| | |
| |----- Payment Gateway API -----|
| |
|
|----- Describe System Behavior and Logic -----|
| |
| |----- Use Cases -----|
| | |
| |----- Flowcharts -----|
| | |
| |----- Pseudocode -----|
| |
|
|----- Evaluate System Design and Validate Requirements -----|
| |
| |----- Performance Testing -----|
| | |
| |----- Prototyping -----|
| | |
| |----- Security Testing -----|
| | |
| |----- User Acceptance Testing -----|
| | |
| |----- Considerations -----|
| | |
| |----- Trade-offs -----|
| | |
| |----- Limitations -----|
|
|----- End
4.2 Produce a model of a software system.
Creating a model of a software system, especially for a complex application like an electronic
and appliance retail store website, involves using various modeling techniques to represent
different aspects of the system. In this case, I'll provide examples of three essential types of
models: Use Case Diagram, Class Diagram, and Data Flow Diagram.
1. Use Case Diagram:
A Use Case Diagram represents the interactions between the users and the system. Here's a
simplified version for the electronics and appliance retail store website:
usecaseDiagram
usecase (User) as User
usecase (ProductSearch) as 'Product Search'
usecase (ProductDetails) as 'Product Details'
usecase (ShoppingCart) as 'Shopping Cart'
usecase(Checkout) as Checkout
usecase(UserAccount) as 'User Account'
usecase (Admin) as Admin

User --> 'Product Search'

User --> 'User Account'
User --> 'Shopping Cart'
User --> Checkout
User --> 'Product Details'
Admin --> 'User Account'
 Admin --> 'Product Management'

'Product Search' --> 'Product Details'

'Product Details' --> 'Shopping Cart'
'Shopping Cart' --> Checkout
2. Class Diagram:
A Class Diagram represents the static structure of the system, showing classes, their attributes,
methods, and relationships. Here's a simplified version:
class Diagram
class User {
-username: String
-password: String
-email: String
+login (): void
+searchProduct (): void
+addToCart (): void
+checkout (): void
}

class Product {
-productid: int
-name: String
-price: float
+get Details (): void
}

class Shopping Cart {

-items: List<Product>
+add Item (): void
+remove Item (): void
+calculate Total (): float
 }

class Order {
-orderId: int
-products: List<Product>
-total Amount: float
+process Payment (): void
}

class Admin {
-adminId: int
-username: String
+manage Products (): void
+manage Orders (): void
}

User --> Shopping Cart

User --> Order
Admin --> Product
3. Data Flow Diagram (DFD):
A Data Flow Diagram represents how data flows through the system processes. Here's a
simplified version with three main processes - User Interaction, Order Processing, and Product
Management:
flowchart
input --> User Interaction --> Order Processing --> output
User Interaction --> Product Management --> output
In this DFD:
Input: Represents the data and requests coming from users and administrators.
User Interaction: Represents the processes related to user interactions such as searching, adding
items to the cart, and managing user accounts.
Order Processing: Represents the processes related to order management and payment
processing.
Product Management: Represents the processes related to managing products, including adding
new products and updating existing ones.
Output: Represents the responses and data sent back to users and administrators.
Please note that these models are simplified and serve as a starting point. Depending on the
specific requirements of your electronics and appliance retail store website, you might need to
create more detailed and intricate models.
Delivering a security and control plan for an electronic and retail location site is critical to
guarantee the insurance of client information, secure monetary exchanges, forestall unapproved
access, and keep up with the honesty of the framework. This is the way you can plan the security
and control estimates utilizing displaying methods:

4.3 Security and Control Plan for Electronic and Retail location Site
1. Verification and Approval:
classDiagram
class Client {
-username: String
-secret word: String
-email: String
+login (): Boolean
+logout (): void
+resetPassword (): void
+authorize (role: String): Boolean
}

class Administrator {
-adminId: int
-username: String
-secret word: String
+login (): Boolean
 +logout (): void
+resetPassword (): void
+manage Products(): void
+manage Orders(): void
}

Client - - |> Administrator: Legacy

In this class graph, Client and Administrator classes have strategies for verification (login,
logout, resetPassword) and approval (approve). Clients and overseers should validate prior to
getting to the framework, and their jobs decide their authorizations.

2. Information Encryption:

Duplicate code
component Diagram
member Client
member Webserver
member Data set
member PaymentGateway

Client - - >|HTTPS| Webserver: Secure Association

Webserver - - >|SSL/TLS| Data set: Scrambled Information
Webserver - - >|SSL/TLS| PaymentGateway: Encoded Information
This part graph shows secure associations between the client, web server, data set, and
installment passage. HTTPS guarantees encoded correspondence between the client's program
and the web server, while SSL/TLS scrambles information communicated between the web
server, data set, and installment door.

3. Input Approval and Sterilization:

sequenceDiagram
member Client
 member Webserver
member Information base

Client - >> Webserver: Send Info Information

Webserver - >> Webserver: Approve and Disinfect Info
Webserver - >> Information base: Store Approved Information
Information base - - >> Webserver: Affirmation
Webserver - - >> Client: Affirmation Reaction
In this succession chart, input information given by the client is approved and disinfected on the
web server prior to putting away it in the data set. Approved information is then affirmed back to
the client, guaranteeing that main cleaned and safe information is handled.

4. Access Control and Logging:

activity Diagram
begin
on the off chance that (Client Solicitations Access)
on the off chance that (Client is Confirmed)
on the off chance that (Client has Authorization)
log ("User Got to Asset")
// Perform approved activity
else
log ("Unauthorized Access Endeavor")
// Deny access, show mistake
end
else
log ("Unauthenticated Access Endeavor")
// Divert to login page
end
else
log ("Invalid Solicitation")
 // Show blunder message
end
stop
This action chart addresses the entrance control process. In the event that a client demands
access, their confirmation and consents are checked. In the event that the client is validated and
has the expected authorizations, the activity is logged, and the approved activity is performed.
On the off chance that the client isn't verified or needs authorizations, access is denied, and the
occasion is logged likewise.

These displaying methods give a visual portrayal of the security and control plan for the
electronic and retail location site, guaranteeing a solid, controlled, and easy to understand
insight. Remember that these models are rearranged, and genuine execution might require extra
safety efforts in light of the particular prerequisites and potential dangers looked by the site.