System Analysis and Design
វិ
គ និងឌីហ ញ បព័ន
System Analysis and Design
I.
េសចកីេផីម
េតីអី
System Analysis and Design?

រវ ិ គ បព័ន (System Analysis):
រកប

II. ដំ
ត មវ
រ លទ
“េតី បព័ន តវ
រេធីអី?”
ព និងមុខ
ដំេណីរ
ដំេណីរ
ដូច
របេងីតគ មរបស់ បព័ន និងកំណត់រច
ែដលសួរ
“េតី បព័ននឹងដេំ ណីរ
ក់
កុ ង System Analysis and Design
លេ
ក
ំ ុង
IT projects មួយ តវ
ច
របេងីត
ក់ដេំ ណីរ
នបេងីត នង
ិ ដំេណីរ
ក់ ណិជកម សម សប
រ និងែថ
រ តវ
មួយនឹងថវ ិ រ និង
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
តេ
េលីសំណួរែដលសួរ
រៃនេរ បចំគេ
ងកុ ង
សម័នរបស់ បព័ន។
េ
របេងីត បព័ន
តេ
េលីសំណួរ
អី?
System Development Life Cycle (SDLC) គឺ
ប់ែណ
េ
៉ ងដូចេមច?”
េតី System Development Life Cycle (SDLC)
ស
រសិក បព័នកុ ងក មិតលមត
ិ វិ គ
រេផ ងៗរបស់ បព័ន។
រឌហ
ញ បព័ន (System Design):
ី
រ
រៃន
ដំេណីរ
ំ បព័ន។
មត មវ
រែដល
នលកណៈ
ផល់នូវលទ
ពកុ ង
ររបស់អតិថិជន តវនឹងេ
ក់ឲ ដំេណីរ
រ
ន់េពលេវ
រច
សម័ន
រេធីឲ បកដ
លបំណងរបស់
។
1
System Analysis and Design
System analysis and design (SAD) គឺ ដំេណីរ
និងប
របស់
ជីវកម ប
ប់មកេរ បចំ បព័នព័ត៌
រ
បព័នកុ ង
រែសងយល់អំពត
ី មវ
នថី ឬែកលម េដីម ប
ី ំេពញត មវ
រ
ង
ំ េ
រ
ះ។
1. System Planning
"េតីេយីងកំពុងេ ះ


យប
អី េហីយេតី គួរែតេ ះ
េ
លបំណង: កំណត់មូលេហតុ
េ
ងវ ិ
ល
សកម
ព:
o
o
េហតុអី តវ
ពគេ
ង។
រកំណត់ប
(េតី
នអីខុស
នង
ិ េ
លបំណង
កំណត់េ
លេ
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
យែដរឬេទ?"
រ បព័នថី កំណត់ េតី
ចេ
រួចឬេទ និង
មួយ បព័នបចុ ប ន)
2
System Analysis and Design
o
េធី
រសិក លទ
ព:

លទ
ពបេចកេទស - េតីេយង
ី
នបេចកវ ិទ េធី ឬេទ?

លទ
ពេសដកិច - េតី សមនង
ឹ តៃមែដរឬេទ និង នលទ

លទ
ព បតប
ិ តិ

លទ
ពផូ វច ប់ និង
រ – េតីអកេ បី
ពេធី ឬេទ?
ស់នង
ឹ ទទួលយក នង
ិ េ បី
លវ ិ គ – េតី
ស់ ែដរឬេទ?
នឧបសគែផកច ប់ ឬេពលេវ
ែដរ
ឬេទ?
o
បេងីត project plan

Input: ប
ជីវកម ឬឱ
ស

Output: Feasibility report and Project Plan
2. System Analysis
"េតី បព័ន តវ រេធី អី?"

េ
លបំណង: ែសងយល់ពី បព័នបចុ ប ន (េ

សកម
យៃដ ឬកុំព ូទ័រ) នង
ិ បមូលត មវ
រ។
ព:
o
បមូលទិនន័យ (interviews, questionnaires, document reviews, observation)
o
កំណត់ត មវ
o
បេងីត process models (DFD – Data Flow Diagrams)
o
បេងីត data models (ERD – Entity Relationship Diagrams)
o
កំណត់ system inputs, outputs, processes, and data
រអកេ បី
ស់ នង
ិ បព័ន

Input: Project plan, ព័ត៌
ន បព័នែដល

Output: System Requirements Specification (SRS)
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
ន
ប់
3
System Analysis and Design
3. System Design
"េតី បព័ននឹងបំេពញ មត មវ រ ៉ ងដូចេមច?"

េ
លបំណង:

សកម
o
o
ស់បូ រត មវ
រេ
បង់េមលមត
ិ ៃន បព័នថី។
ព:
Logical design (េតីអែី ដល បព័នគួរេធ)
ី :

កំណត់ត មវ
រ user interface (UI)

កំណត់ inputs, outputs, and processes
Physical design (រេប បែដល នឹងដំេណីរ
រ):

Database design (tables, keys, relationships)

Program structure (modules, classes, functions)

Hardware/software specifications

Input: SRS document

Output: System Design Document (SDD)
4. System Development (Coding/Construction)
"ដេំ ណីរៃន របេងីត បព័ន"

េ
លបំណង: បំែបង

សកម
រ design េ
បព័ន េ
យសរេសរកូដ នង
ី databases។
ិ បេងត
ព:
o
េ ជីសេរស
ី programming language, framework, and database
o
សរេសរ application code (frontend + backend)
o
បេងីត database structure នង
ិ ប ូ ល test data
o
រួមប ូ ល system modules
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
4
System Analysis and Design

Input: System design specifications

Output: Working System/Prototype
5. System Testing
"េតី បព័នដេំ ណីរ រ ន តឹម តវឬេទ?"

េ
លបំណង:

សកម
កដ
បព័នដំេណីរ
រដូ ចបំណង នង
ិ បំេពញ
រអកេ បី
ស់។
ព:
o
េតសែផកនម
ី ួយៗ → េតស individual modules
o
េតស
o
េតស បព័ន
o
េតស
រទទួលយករបេសីអកេ បី
េផ ង
ត់ មួយអកេ បី
o
មត មវ
រួម → ពន
ិ ត
ិ modules ែដលដំេណីរ
ង
ំ មូល → េតសមុខ
រ បព័ន
រ
មួយ
ង
ំ មូល
ស់ User Acceptance Testing (UAT) →
ស់ចុងេ
យ
Debugging and fixing errors

Input: Developed system.

Output: Tested and error-free system
6. System Deployment
" ក់ បព័នេ កុ ង រេ បី

េ
លបំណង:

សកម
o
ស់ ក់ែសង"
ក់ដំេណីរ
រ បព័នថីេ
កុ ងអង
ព
ព:
System installation (on servers, client machines)
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
5
System Analysis and Design
o
Data migration (from old system to new system)
o
User training & user manuals

Input: Tested system

Output: Operational System in real environment
7. System Maintenance
"រក បព័នឲ ដេំ ណីរ រ និងែកលម"

េ
លបំណង: តវ

សកម
កដ
បព័នបនដំេណីរ
រ
ន តឹម តវប
ប់ពី ក់ឲ ដំេណីរ
រ។
ព:
o
រែថ
ែំ កត មវ → Fix errors ប
o
រែថ
ឲ
ំ តវេ
េពលបរ ិ
រែថ
o
មស
ប់ពី ក់ឲ ដំេណីរ
រ
ព (Adaptive maintenance) → Update system េ
ន បព័នែ ប បល
ឲ
ំ លេឡង
ី → ែកលមដំេណីរ

Input: Operational system

Output: បព័នែដល
រ ឬបែនមមុ ខ រថីៗ
នែកលម នង
ិ េធីបចុ ប ន
ពែដលបនបំេពញត មវ
រ
ជីវកម
ប់
កុ ង
III. System Analysis and Design Approaches
Waterfall Approach:
ធម
ន 6 ដំ
ក់ លសំ
Waterfall Model គឺ វ ិធី
ស
នលកណៈ
ែខ ប

បព័ន ែដលដំ
នេគេ
រហូតដល់
ក់ លនីមួយៗ តវែតប ប់ឲ រួច ល់ មុនេពល
Waterfall េ
ររច
រអនុ វត
យ
រែតដំេណីរ
រេធេី តស
រ
ររបស់ ហូរចុះេ
ក់ឲ ដំេណីរ
ន់ៗ
ត់ និងបនប
ប់េផីមដំ
ក់ លប
មដូ ច ទឹកេ
រ នង
រែថ
ិ
ះ
រអភវិ ឌ ន៍
ប់។
តវ
ប់ពត
ី មវ
រ
ំ (from requirements to
design, implementation, testing, deployment, and maintenance )។
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
6
System Analysis and Design

Agile Approach
Agile Approach គឺ វ ិធី
សេធីដែដលៗ (iterative) នង
ិ ព ងីកបែនម (incremental)
មួយស
ប់បេងីត software ។ ជំនស
ួ ឱ
បព័ន
ែផកតូចៗែដល
ច គប់ គង
របេងីត បព័នធំមួយ (ដូច
នែដលេ
iteration ឬ sprint។
Iteration នីមយ
ួ ៗបេងីតនូ វែផកមួយៃន software ែដល តវ
េ
យែផកេលីមតែិ កលមពីអកេ បន
ី ិង
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
Waterfall) Agile បេងីត
នពន
ិ ិត យតៃម និងែកលមេឡង
ី
គី ក់ពន
័ ។
7
System Analysis and Design
Object-Oriented Approach

Object-Oriented Approach (OOA) គឺ វ ិធី
and design ែដលេ
តេ
េលី objects - real-world entities
processes។ Object នម
ី ួយៗតំ
Product, or Order) ែដល
េ
ន:
ងឲ វតុ (thing) មួយេ
o
Attributes (data/properties), នង
ិ
o
Methods (operations/behaviours)
ងេ
កុ ងពិភពេ
នេ
តេ
រេធី system analysis
េលី functions ឬ
កុ ង system (ដូច
លបំបងគេឺ ដីម េី ធីគ ម system ែដល សេដ ង និងឆុ ះប
ទំ ក់ទំនងេ
ជំ
សទំេនប
ី មួយកុ ង
កពត
ិ ។
ង
ំ េ
Customer,
នង
ឹ វតុ (things) នង
ិ
កុ ង Object-Oriented System Development
Phase
Description
Output
1. Object-Oriented
Identify objects, their
Use Case Diagrams,
Analysis (OOA)
relationships, and interactions.
Class Diagrams, Object
Models
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
8
System Analysis and Design
2. Object-Oriented
Define how objects interact
Detailed Class Diagrams,
Design (OOD)
through methods and
Sequence Diagrams
relationships.
3. Object-Oriented
Implement the design using an
Programming (OOP)
OOP language like Java, C++, or
Source code files
Python.
4. Object-Oriented
Testing (OOT)
IV. Use Case - Unified Modelling Language (UML)
េតី Use Case Diagram គឺ
អី?
Use Case Diagram គឺ
រប
ញ
(actor) េធីអនរកម មួយ បព័ន និងមុ ខ
បព័នេធី មិនែមនរេប បែដល េធីេ
សម័ន (structure) េទ។
លកណៈរូប
ញពីរេប បែដលអកេ បី
រ (use cases) ែដល បព័នផល់ឲ ។ េ
ះេទ ដូេចះ និ
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
ព ែដលប
យអំពត
ី មវ
ស់
តេលីអីែដល
រ និងអនរកម មន
ិ ែមនកូដ ឬរច
9
System Analysis and Design
េ
លបំណងចម ង

េដីម ក
ី ំណត់ ពំែដន បព័ន

េដីម យ
ី ល់ពេី

េដីម ប
ី
ញមុ ខ
រ បព័ន

េដីម ប
ី មូល
ី េងត
ន គះឹ ស
លេ
របស់អកេ បី
មទស នៈរបស់អកេ បី
ប់ Data Flow Diagrams, Class Diagrams, and System
Design
Key Components of a Use Case Diagram
Symbol
Element
Actor
Description
Example
A person, system, or
Customer, Admin,
device that interacts
Payment Gateway
with the system.
Use Case
System Boundary
A specific function or
Place Order, View
action the system
Product, Make
performs for an actor.
Payment
A box that defines the
“Clothes Store
scope of the system
System”
— what’s inside vs.
outside.
Association Line
A line connecting an
Customer — Place
actor to the use
Order
case(s) they interact
with.
<<include>>
Include
---------->
Relationship
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
When one use case
Place Order →
another.
Product
always includes
includes Select
10
System Analysis and Design
<<extend>>
Extend
---------->
Relationship
Generalization
When one use case
Make Payment →
another.
Discount
optionally extends
extends Apply
When one actor or
Admin is a special
use case inherits
kind of User
behaviour from
another.
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
11
System Analysis and Design
V. Data Flow Diagram
េតី Data Flow Diagram (DFD)
អី?
Data Flow Diagram (DFD) គឺ
modelling tool ដ៏សំ
and Design។ Data Flow Diagram (DFD) ប
រេប បែដល តវ

ប
នដេំ ណីរ
រ។
ន់បំផុតមួយេ
ញពីរេប បែដលទិនន័យ
កុ ង System Analysis
ស់ទីេ
កុ ង បព័ន និង
ញ:
o
Processes (transformations of data)
o
Data flows (movement of data between processes, stores, and entities)
o
Data stores (where data is kept)
o
External entities (sources/destinations of data, e.g., users, other systems)
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
12
System Analysis and Design
និមត
ិ ស
ែដលេ បក
ី ុ ង DFD
Symbol
 Process (Circle/Ellipse)
Meaning
Represents a function or activity (e.g.,
"Validate Login")
 Data Store (Open Rectangle)
Where data is stored (e.g., "Database",
"Files")
 External Entity
(Square/Rectangle)
 Data Flow (Arrow)
Outside system boundary (e.g., "Customer",
"Bank")
Movement of data between entities,
processes, and stores
https://blog.hubspot.com/marketing/data-flow-diagram
Levels of DFD
1. Level 0 (Context Diagram)
o
High-level view of the system
o
Shows system as a single process with external entities
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
13
System Analysis and Design
Example: Clothes Store Management System
Level 0 (Context Diagram)

Entities: Customer, Admin, Supplier

System: Clothes Store System

Flows:
o
Customer → Order Request → System
o
System → Order Confirmation → Customer
o
Admin → Update Inventory → System
Supplier → Deliver Stock → System
2. Level 1 DFD
o
Breaks the single process into major sub-processes
o
Shows main data stores and flows
Level 1 DFD (Clothes Store Management System)

Main Processes:
1. Manage Products (add/update/delete/search product)
2. Process Orders (customer order handling)
3. Handle Inventory (stock management)
4. Manage Accounts (login, roles: admin/modifier)
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
14
System Analysis and Design


Data Stores:
o
Product Database
o
Order Database
o
User Database
Flows:
o
Customer → Place Order → Process Orders → Order Database
o
Admin → Manage Products → Product Database
o
Supplier → Deliver Stock → Handle Inventory → Product Database
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
15
System Analysis and Design
3. Level 2 (and lower)
o
More detailed breakdown of processes
o
Explains how each process works internally
VI. Entity relationship Diagram
Entity-Relationship Diagram (ERD) គឺ

data modelling technique ែដលប
ញព៖
ី
Entities → Objects in the system (tables in a database) - is a real-world object,
person, place, or concept for which a database stores information. In the context
of database design, each entity often corresponds to a database table

Attributes → Properties of each entity (fields/columns)

Relationships → How entities are connected (one-to-one, one-to-many, many-tomany)
ERD Symbols
https://tutorialwing.com/er-diagram-in-dbms-components-symbol-and-notations/
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
16
System Analysis and Design
Name
Strong Entity
Description
Can exist independently; has a
Example
Customer, Product, Order
unique identifier (primary key)
Weak Entity
Simple Attribute
Depends on another entity for
OrderItem,
existence. Usually has a partial key
PaymentDetail
Cannot be divided further
Name, Email
Composite Attribute Can be divided into smaller parts
FullName → FirstName,
LastName
Derived Attribute
Calculated from other attributes
Age (derived from
DateOfBirth)
Multivalued
Can have multiple values
PhoneNumbers
Represents a logical connection
One Customer can have
between entities
many Orders
Used when a weak entity depends
Order ◆— contains —◆
on a strong entity
OrderItem
A unique identifier for an entity —
CustomerID ← (Primary
distinguishes one record from
Key)
Attribute
Relationship
Weak Relationship
Primary Key (PK)
another
Foreign Key (FK)
Cardinality
An attribute that creates a
CustomerID in Order
relationship between two entities
table
Defines how many instances of one
One customer places
entity relate to another
many orders
Types of Relationships (Cardinality)
1. One-to-One (1:1)
One entity instance is related to one instance of another entity.
Example: User ↔ Profile
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
17
System Analysis and Design
2. One-to-Many (1:N)
One entity instance is related to many instances of another.
Example: Customer → Order
3. Many-to-Many (M:N)
Many instances of one entity relate to many of another (usually resolved with a
linking table).
Example: Order ↔ Product (via OrderDetail)
Quick Visual (Crow’s Foot Notation)

|| = Exactly one

O| = Zero or one

|< = One or many

O< = Zero or many
ដូេចះ

Customer (1) — < Order (Many)

Order (1) — < OrderDetail (Many)

Product (1) — < OrderDetail (Many)
រែណ

អ
ំ ំពី
របេងត
ី ERD:
កំណត់ Entities: ជំ
ំ ូងកុ ង
នដប
របេងីត ERD គឺកណ
ំ ត់ entities
ង
ំ អស់ែដលអកនង
ឹ
េ បី។ Entities គឺ អីមួយែដល បព័នរបស់អកនឹងរក ទុកព័ត៌ នអំពី ។
manager, invoice, schedule, etc។ គូរចតុេ
ចគត
ិ ដល់េ
េលី ក
សរបស់អក។ ទុកគ
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
ណែកងស
តឱ
ត
ច
customer,
ប់ Entities នម
ី ួយៗែដលអក
យពី បនិច។
18
System Analysis and Design

កំណត់ Relationship: េមល
ី Entities ពរី េតី
ប
ត់មយ
ួ ត
រពិពណ៌
ប់ Entities
ក់ទន
ំ ង
ឬេទ? េបី

បែនម Attributes: Attributes សំ

ប
ក់ទង
ន់ៗមួយចំនួនគួរែតបែនមេ
ប់ Entities េ
មួយនង
ឹ
(Cardinality)។
យេ បរី ូបពង កេពី (oval)។
យេ បីែខ រប ត់ េហយ
ី បែនមរូប diamond រ ង
Entities និង ក់ Cardinality រហូតដល់អស់។ Entities ខះ បែហល
េទ ខះ
នសូមគូសែខ រ
ង
ំ ពីរ េហយ
ី បែនមរូប diamond រ ង Entities ពួក
អំពរី េប បែដលពួក
ប់ Diagram: បន
នទំ
មិន
ន Relationship
ច Relationship េ ចន
ី ។
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
19
System Analysis and Design
Types of Entity Relationship Diagrams
Traditional ERD
Traditional Chen ERD
នរូប ងដូច flowchart ែដល
relationships, នង
ិ attributes។
បេងីតេផ ងេទ ត ប៉ុែននិមិតស
ដូច
តវ
មូល
នបេងីតេ
នែដល
យេ
នរូបស
entities,
ក Peter Chen ចំេ
នេ បី និងរេប បែដលពួក
ះអកេផ ងេទ ត
ប់
នទំេ
ន
រេមីលេ
។
IDEF1X Notation ERD - Relational Schema
IDEF1X មកពី
នឹងប ញ entities
តេ ម ប
ក integrated definition for data modelling។ ER diagram បេភទេនះ
ប់ មួយ
ែផកមួយរបស់
អកមួយចំនន
ួ េ
ងេ
េ
យ
ន relationship symbols។ attributes របស់ entity នឹង
ំ ួយឲ
កុ ង entity shape នម
ួ ៗ ជន
ី យ
ER diagram េនះ
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
រេ បី
ស់ symbols េផ ង។
Relational Schema diagram។
20
System Analysis and Design
ERD Models
Entity Relationship Models
យកមកេ បី
ស័យេលក
ី មត
ិ ៃន
ស័យេលី
រចង់ប
រលមត
ិ ែដលេគចង់ប
ញ។
ធម
នបី បេភទែដលអកេ បី
ញ។
នដូច
Conceptual ERD,
ន
ពអរូបី និងព័ត៌
Logical ERD, និង Physical ERD។

Conceptual ERD or data model: Model េនះ
សម សបស
ប់គេ
Conceptual ERD
ងធំែដល តវ
រទដ
ិ
ពក មត
ិ ខស់ែដលេ បេី
ន Entity និង Relationship ប៉ុែនមិនផល់ព័ត៌
columns ឬ cardinalities េទ។
ទដ
ិ
នលមិតតច
ិ បំផុត ដូេចះ
យអកវ ិ គ
ជីវកម។
នលមិតអំពី database
ពទូេ
នង
រប
ិ
ញ ក មិតទូេ
ៃន database
Logical ERD or data model: Model េនះ បែនម
ពលមិតេ
េលី conceptual model េ
បែនម attributes នង
ិ កំណត់ Entity បែនម ែដល
ន បតប
ិ តិ
រ។
design ។


Physical ERD or data model: Model េនះ ប
database រួមប ូ ល
ញពី
រកំណត់ cardinality និងប
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
រឌហ
ញពត
ី
ិ ឬ
យ
បង់របស់
ញ primary និង foreign keys របស់
21
System Analysis and Design
entities។ ERD បេភទេនះ attributes របស់ នង
ឹ តវសរេសរ
ប់ េដីម ប
ី
ញ columns
របស់ database table ពិត។
Example ERD: Clothes Store System
Entities we might need:
1. Customer
o
CustomerID (PK)
o
Name
o
Email
o
Phone
o
Address
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
22
System Analysis and Design
2. Product
o
ProductID (PK)
o
Name
o
Category
o
Price
o
StockQuantity
3. Order
o
OrderID (PK)
o
OrderDate
o
TotalAmount
o
CustomerID (FK)
4. OrderDetail (resolves many-to-many between Order and Product)
o
OrderDetailID (PK)
o
OrderID (FK)
o
ProductID (FK)
o
Quantity
o
Subtotal
5. User (for Login/Admin)
o
UserID (PK)
o
Username
o
Password
o
Role (Admin / Modifier / Customer)
6. Supplier
o
SupplierID (PK)
o
Name
o
ContactInfo
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
23
System Analysis and Design
7. Inventory
o
InventoryID (PK)
o
ProductID (FK)
o
SupplierID (FK)
o
StockAddedDate
o
QuantityAdded
Relationships

Customer → Order: 1-to-Many (one customer can make many orders).

Order → OrderDetail → Product: Many-to-Many (an order can have many
products, a product can appear in many orders).

Product → Inventory → Supplier: Many-to-Many (products can come from many
suppliers, suppliers can provide many products).

User → Customer/Admin: One-to-One (each user has one role, linked by
UserID).
VII. Class Diagram - Unified Modelling Language (UML)
Class Diagram គឺ
Diagram ។
ប
Diagram ដ៏សំ
ញពី structure ែដល
ន់មយ
ួ េ
ក់
កុ ង UML (Unified Modelling Language)
ក់មួយរបស់ system — the classes, attributes,
methods (operations), នង
ិ relationships របស់ពួក ។
Elements of a Class Diagram
Symbol / Element
Class (Rectangle divided
into 3 parts)
Description
Represents a class with
name, attributes, and
methods.
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
Example
Customer
— name: String
— email: String
+ register()
24
System Analysis and Design
Abstract Class (Italic name
Cannot be instantiated,
or marked with {abstract})
used as a base class.
Interface (<<interface>>)
Defines behaviour without
implementation.
Shape
<<interface>> Payment
Variables inside a class.
Attributes
Visibility: + public, - private,
- id: int
# protected.
Functions inside a class,
Methods (Operations)
with visibility and return
+ getName(): String
type.
Association (Line)
Shows relationship
between two classes.
Customer —— Order
Defines how many objects
Multiplicity
participate:
Customer 1 —— * Order
1, 0..1, * (many), 1..*
Aggregation (Hollow
Diamond)
“Has-a” relationship,
whole-part but
independent.
Composition (Filled
Stronger whole-part,
Diamond)
dependent lifecycle.
Inheritance (Triangle
Arrow)
Department ◇— Employee
Order ◆— OrderItem
“Is-a” relationship.
Subclass inherits
Person △— Student
superclass.
Dependency (Dashed
Class depends on another
Arrow)
temporarily.
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
Invoice - - > Printer
25
System Analysis and Design
Example: Clothes Store Class Diagram
ប
ញ:

Customer → Order (1 to many)

Order ◆→ OrderItem (composition, strong ownership)

OrderItem ↔ Product (association, many order items link to products)
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
26
System Analysis and Design
VIII.
System Design

Physical Design (Database and Program structure)

Logical Design (User Interface)
េរ បេរ ង និងែ បស មល៖ Msc. Sok Savang
27