Bài giảng Phân tích và thiết kế hệ thống thông tin - Phần 4: Thiết kế hệ thống - Nguyễn Anh Hào

Thiết kế hệ thống 2

• Thiết hệ thống theo hướng đối tượng nhằm xây dựng mô hình

cho phần mềm giống với thế giới thực: các lớp đối tượng đều

gắn với thực tế (để dễ hình dung ra kết cấu của phần mềm).

• Các vấn đề trong thực tế đều có lời giải trong thực tế. Sự mô

phỏng thực tế qua cách mô hình hóa ở phần phân tích cũng đã

thể hiện giải pháp được áp dụng trong thực tế; do đó trong

OOAD, việc phân tích cũng đồng nghĩa với thiết kế khi xem xét

vấn đề - giải pháp ở khía cạnh ý niệm (nội dung thông tin).

• Việc thiết kế hướng đối tượng tập trung vào khía cạnh cài đặt

các ý niệm thành phần mềm có đặc điểm dể sửa, và để dùng

lại cho nhiều ứng dụng khác nhau.

pdf42 trang | Chuyên mục: Phân Tích Thiết Kế Hệ Thống | Chia sẻ: yen2110 | Lượt xem: 673 | Lượt tải: 3download
Tóm tắt nội dung Bài giảng Phân tích và thiết kế hệ thống thông tin - Phần 4: Thiết kế hệ thống - Nguyễn Anh Hào, để xem tài liệu hoàn chỉnh bạn click vào nút "TẢI VỀ" ở trên
ional DB, RDB) 
cho OOAD như thế nào ?
10
RDB: cài đặt lớp thực thể (entity class)
Thuộc tính : bảng quan hệ trong RDBMS.
Thuộc tính khóa: là số nguyên (ID) 
Lớp thực thể không có phương thức
Circle
X-coord
Y-coord
Radius
Color
C_ID X_coord Y_coord Raius Color
001 5 5 7 red
002 5 7 3 blue
003 8 -8 10 yellow
CIRCLE
11
RDB: Quan hệ kế thừa
Cá nhân (ID, tên, tuổi)
Nhân viên (ID, vai trò, nhiệm vụ)
Bác sỹ (ID, Chuyên môn)
(ISA)
(ISA)
Nhân viên
-tên,tuổi
-Vai trò
- Nhiệm vụ
Cá nhân
-tên, tuổi
Bác sỹ
-tên,tuổi
-Vai trò
-Nhiệm vụ
-Chuyên môn
12
RDB: Quan hệ kế thừa (2)
13
RDB : Association (1 - *)
Bệnh nhânBác sỹ
Điều trị
1 *
Bệnh Nhân
-My doctor : BS
Bác Sỹ
-My Patients[ ]: BN
+ĐieuTri (x:BN)
Bác sỹ ( ID# )
Bệnh nhân ( ID# , BS )
điều trị
14
RDB : Association (2)
15
RDB : Association (* - *)
ProjectEmployee
* *
Work_on
Hours
Start_date
Work_on
-E: Employee
-P: Project
-Hours
-Start_date
Employee( EID# ) Project( PID# )
Work_on (ID, E#, P#, Hours, Start_date)
16
RDB : Association (2)
17
RDB : Aggregation ( Association 1-*)
Bike
Wheel
Bike
-List of (Wheel)
A "uses" B = Aggregation : B exists independently (conceptually) from A
Bike ( ID# )
Wheel ( ID# , Bike)
(BELONG TO)
Wheel
-Is of: Bike
18
RDB : Composition
Person
Leg Arm
Person
-MyLeftArm : Arm
-MyRightArm : Arm
-MyLeftLeg : Leg
-MyRightLeg : Leg
A "owns" B = Composition : B has no meaning or purpose in the system 
without A
Person ( ID# , L_Arm, R_Arm, L_Leg, R_Leg)
Arm ( ID# ) Leg ( ID# )
19
RDB : Composition (2)
20
Nội dung thiết kế
1. ÁNH XẠ LỚP PHÂN TÍCH THÀNH LỚP THIẾT KẾ
2. CSDL: ÁNH XẠ MÔ HÌNH ĐỐI TƯỢNG SANG MÔ 
HÌNH QUAN HỆ
3. THIẾT KẾ CÁC THÀNH PHẦN, SUBSYSTEM VÀ 
PACKAGE
4. THIẾT KẾ KIẾN TRÚC CHO HỆ THỐNG
21
Thiết kế các thành phần
• Hệ thống phần mềm = tập hợp các thành phần liên kết nhau để 
xử lý công việc chung của phần mềm.
• Mỗi thành phần (conponent) của hệ thống, theo nghĩa của thiết 
kế, là đơn vị nhỏ nhất (lớp đối tượng) của hệ thống phần mềm.
– Mỗi thành phần chỉ giải quyết vấn đề cơ bản, phổ thông.
• Một số thành phần được gộp lại thành một hệ thống con 
(SubSystem) cho hệ thống ( 1 lớp gồm nhiều lớp con)
– SubSystem giải quyết vấn đề chuyên biệt của hệ thống. 
• Một số thành phần cũng được gộp lại thành gói (Package) để 
hiện thực thành phần mềm ( thư viện để sử dụng)
– Package tạo ra tiện nghi cho việc phát triễn và sử dụng lại 
các thành phần đã thiết kế.
22
Tính Cohesion của lớp
• Là mức độ cần dùng lẫn nhau giữa các lớp, xét trên 
vai trò của hệ thống hoặc hệ thống con
– Sự cộng tác dựa trên tính “chuyên nghiệp”: mỗi lớp chỉ 
xử lý cho một vấn đề (single responsibility).
• Đặc điểm của lớp để hổ trợ cho cohesion :
1. Method: Mọi thành tố bên trong phương thức đều hết 
sức cần thiết cho phương thức đó.
2. Class: mọi phương thức và thuộc tính của lớp đều rất 
cần thiết cho nhiệm vụ (duy nhất) của lớp.
3. Inheritance: Mọi lớp con đều cần thiết và không thừa, 
để làm thỏa mãn nhiệm vụ (đa dạng) của lớp cơ sở.
23
Tính Coupling của lớp
• Phụ thuộc lẫn nhau: do có cộng tác trong hệ thống.
– Sự thay đổi có thể làm phụ thuộc bị vi phạm → ít phụ 
thuộc thì hệ thống sẽ dể sửa.
• Các loại phụ thuộc giữa 2 lớp (B phụ thuộc vào A):
• Interaction: khi B kích hoạt (gọi) phương thức của A
– B phụ thuộc vào tên và tham số của phương thức này
• Inheritance: B thừa kế từ A
– B có sử dụng nội dung thừa kế từ A thì B sẽ bị phụ 
thuộc vào A vì nội dung thừa kế này.
• Component: Khi B có biến được khai báo là kiểu A
– B cũng bị phụ thuộc vào tất cả các lớp con của A
24
Kiểu dữ liệu trừu tượng
• Abstract Data Type (ADT): dữ liệu được cài đặt như là 
một lớp đối tượng:
– Các thuộc tính có cấu trúc, kiểu, được che kín;
– Chỉ có các phương thức truy cập (sử dụng) các thuộc 
tính này được cung cấp công khai.
• ADT được dùng để che giấu cấu trúc lưu trữ của dữ 
liệu, nhờ vậy mà các đối tượng sử dụng dữ liệu này 
không bị phụ thuộc vào cấu trúc lưu trữ của chúng.
25
ADT – ví dụ (1)
Địa chỉ nhà được cài đặt trong C++ như sau:
class CustInfo
{ 
public char Addr[40];
}
Cài đặt này sẽ gặp khó khăn gì khi phát triễn phần mềm ?
Nhiều nơi sử dụng phải biết điều này:
1. Đây là kiểu zero string (C chuẩn), kết thúc chuổi là ‘\0’
2. Khi gán : strlen (Addr) ≤ 39 ký tự
3. Quy ước về kết cấu của Addr = “ 
 ” để trích từng thành tố ra dùng. 
Thay vì cung cấp dữ liệu để sử dụng tùy ý; ta cần biết nhu 
cầu sử dụng dữ liệu để cung cấp phương thức xử lý => ADT
26
ADT – ví dụ (2)
Địa chỉ nhà được cài đặt lại trong C++ như sau:
class Address
{ private: // che cấu trúc dữ liệu
char sn[21], duong[41], phg[21], quan[21], tp[21];
public: // cung cấp các phương thức truy cập
int SetAddr(char * s, char * d, char *p, char *q, char * t);
int GetAddr(char * desAddr);
int GetElement(int ElementID, char * desElem)
};
class CustInfo
{ 
public class Address A; // ADT
}
27
Hệ thống con (SubSystem)
• Là một nhóm đối tượng có hợp tác nhau 
để thực hiện một vài nhiệm vụ của hệ 
thống
– Một hệ thống = tập các SubSystem
– Component là SubSystem đơn giản nhất 
(ie, chỉ có 1 class)
– SubSystem cung cấp dịch vụ cho hệ thống 
thông qua Interface của nó
• Thiết kế SubSystem: để phục vụ cho hệ 
thống, không có mục đích sử dụng lại cho 
hệ thống khác (≠ Package)
subsystem
System
SubSystem(s)
Component(s)
28
SubSystem
Use case X
Hệ thống phần mềm
SubSystem
A
SubSystem
B
Component
C
A
B
C
Use case Y
Interface
X Y
Dependency
Class
29
Thiết kế SubSystem-1
1. Phân hoạch hệ thống thành các SubSystem, dựa 
trên lược đồ use case của hệ thống.
– Gộp các SubSystem = hệ thống
– Tương tự như lớp đối tượng, mỗi SubSystem có nhiệm 
vụ riêng biệt, đó là xử lý trọn vẹn một hoặc vài use 
case gắn kết nhau theo các quan hệ , includes và 
extendes.
30
Thiết kế SubSystem-2
2. Thiết kế interface cho SubSystem
– Boundary class được sử dụng cho interface. Chỉ có 
boundary class được nhìn thấy từ bên ngoài; để ngăn 
chặn các truy xuất từ ngoài vào trong SubSystem.
– Là lớp đối tượng cung cấp các tương tác (giao tiếp) cố 
định & tuân thủ đúng nguyên lý SOLID.
– Khộng có lớp đối tượng nào bên trong SubSystem phụ 
thuộc vào lớp này.
– Kiểu dữ liệu trừu tượng (ADT) cho dữ liệu tương tác 
(thông điệp) được khai báo bên ngoài SubSystem.
31
Thiết kế SubSystem-3
2. Thiết kế các tương tác của SubSystem
– Tương tự như use case, mỗi xử lý tương tác trên 
interface được diễn tả bằng ít nhất là một lược đồ chức 
năng (tuần tự, cộng tác, hoạt động)
– SubSystem có ít nhất là 1 lớp đối tượng bên trong.
– Tất cả các lớp bên trong SubSystem đều được ẩn đối 
với môi trường bên ngoài.
– Tất cả các tham chiếu từ trong SubSystem ra ngoài 
đều là các phụ thuộc cần cân nhắc kỹ. 
32
Gói (Package)
• Là một cơ chế nhóm các thành tố thiết kế 
cơ bản (lớp, giao tiếp) thành một cấu trúc 
vật lý duy nhất (vd: “mô đun”) để tiện cài 
đặt và sử dụng.
• Nội dung của Package có thể là
– Một hoặc vài SubSystem;
– Một thư viện các thành phần dùng lại;
– Những lớp cần cài đặt chung với nhau (do 
chúng phụ thuộc nhau)
• Thiết kế Package: tổ chức các lớp (code, 
data) để dể phát triễn, sử dụng và bảo trì.
A B
33
Package dependency
Client
Package (A)
Supplier
Package (B) 
Dependency 
• Package A phụ thuộc package B nếu A có 1 lớp 
phụ thuộc vào 1 lớp nào đó trong B
• Hệ lụy tất yếu là:
– Sự thay đổi ở Supplier Package có thể ảnh hưởng 
đến Client Package
– Client Package không thể được sử dụng lại riêng lẻ, 
vì nó bị phụ thuộc vào Supplier Package
34
Package Visibility & Access
Public 
visibility
Private 
visibility
Chỉ có những 
lớp loại “public” 
mới có thể được 
truy xuất được 
từ bên ngoài
PackageB
PackageA
Class A2
Class A3
+ Class B1 
- Class B2
Class A1
35
Package Coupling
A
B
X
1. Packages should not 
be cross-coupled 
2. Packages in lower 
layers should not be 
dependent upon 
packages in upper 
layers
3. In general, 
dependencies should 
not skip layers
A BX
C
X
X = Coupling violation
Upper 
Layer
Lower 
Layer
36
Nội dung thiết kế
1. ÁNH XẠ LỚP PHÂN TÍCH THÀNH LỚP THIẾT KẾ
2. CSDL: ÁNH XẠ MÔ HÌNH ĐỐI TƯỢNG SANG MÔ 
HÌNH QUAN HỆ
3. THIẾT KẾ CÁC THÀNH PHẦN, SUBSYSTEM VÀ 
PACKAGE
4. THIẾT KẾ KIẾN TRÚC CHO HỆ THỐNG
37
Thiết kế kiến trúc
• Phân hoạch ứng dụng thành từng phần tương đối độc 
lập nhau (subsystem, package) theo chiều dọc 
(layers,tiers) hoặc chiều ngang (partition)
• Giải quyết các vấn đề sử dụng dữ liệu (cập nhật, bảo 
mật,..)
38
PC networking
Peer to peer: 
Different Application domain
Client-server: 
The same application domain
Stand alone PC:
Not sharing
39
“Thinner client, thicker server”
Client 
Presentation
Business 
Logic
Client Presentation
(HTML)
Network: LAN
Network: WAN
Presentation
Business 
Logic
Work
station
Database 
DB Server
DBMS 
DB Server
DBMS 
Web & App Server
Business Logic
(Web API)
Network: LAN
40
Client Server N-tier
1st tier 2nd tier 1st tier 2nd tier 3rd tier
Concurency data update: 
→ Design for Concurency
Undefined client:
→ Design for Security
41
Design for Concurency
1. Do có nhiều truy cập đồng thời vào CSDL, việc thiết 
kế phải bảo đảm rằng dữ liệu được lấy ra sử dụng 
phải chính xác; ie, dữ liệu đang được cập nhật sẽ 
không được truy cập cho tới khi nó được cập nhật 
xong.
2. Bảo đảm rằng dữ liệu sẽ không thay đổi khi nó đang 
được đọc; ie, không xóa mẫu tin khi có ai đó đang 
đọc.
Ví dụ: nếu chỉ có 1 vé máy bay mà có 2 khách hàng 
cùng hỏi để mua, thì hệ thống sẽ hổ trợ đại lý bán vé 
giải quyết như thế nào ?
42
Design for Security
• 5 mức độ an ninh:
1. Privacy: bảo mật cho thông tin riêng (vd: tài khoản)
2. Authentication: xác thực nguồn gốc của thông tin
3. Irrefutabiliy: không thể bác bỏ (chối).
4. Integrity: bảo đảm toàn vẹn dữ liệu, từ nguồn → đích
5. Safety: bảo đảm an toàn cho tài nguyên (dữ liệu, 
chương trình, thiết bị)

File đính kèm:

  • pdfbai_giang_phan_tich_va_thiet_ke_he_thong_thong_tin_phan_4_th.pdf