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.
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:
- bai_giang_phan_tich_va_thiet_ke_he_thong_thong_tin_phan_4_th.pdf