intTypePromotion=1
zunia.vn Tuyển sinh 2024 dành cho Gen-Z zunia.vn zunia.vn
ADSENSE
 » 
 » 

Bài giảng Tích hợp hệ thống: Bài 3 - ĐH Kinh tế Tp HCM

Chia sẻ: Zcsdf Zcsdf | Ngày: | Loại File: PPT | Số trang:21

Thêm vào BST
Báo xấu
156
lượt xem 21
download
 
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Kiến thức cung cấp bài 3 Kiến trúc Module trong bài giảng Tích hợp hệ thống là kỹ thuật phát triển hệ thống theo kiến trúc module: phân tích, thiết kế, lập trình, biết được các tiêu chí đánh giá kiến trúc module. Phân biệt được các kiểu tích hợp module, biết được các công nghệ hỗ trợ lập trình module.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài giảng Tích hợp hệ thống: Bài 3 - ĐH Kinh tế Tp HCM

  1. LOGO TRƯỜNG ĐH KINH TẾ TP HỒ CHÍ MINH KHOA HỆ THỐNG THÔNG TIN KINH DOANH Bài giảng môn TÍCH HỢP HỆ THỐNG BÀI 3: KIẾN TRÚC MODULE
  2. Mục tiêu  Sau khi học xong bài này sinh viên có thể:  Hiểu kỹ thuật phát triển hệ thống theo kiến trúc module: phân tích, thiết kế, lập trình  Biết được các tiêu chí đánh giá kiến trúc module  Phân biệt được các kiểu tích hợp module  Biết được các công nghệ hỗ trợ lập trình module
  3. Tham khảo 1. Nguyễn Văn Vỵ, Nguyễn Việt Hà. Giáo trình kỹ nghệ phần mềm, NXB ĐHQG HN, 2008 2. http://en.wikipedia.org/wiki/Modular_programming 3. Ian Sommerville, Software Engineering 8th Edition, 2007.
  4. Nội dung  Các khái niệm cơ bản về kiến trúc module  Tiêu chí đánh giá kiến trúc module  Các kiểu ghép nối module (tích hợp)  Lập trình theo module
  5. Kiến trúc module  Kiến trúc mô-đun (module) cho phép chia nhỏ bài toán (hay yêu cầu) của phần mềm thành các phần hầu như không trùng lắp và do đó hỗ trợ làm việc song song trên các module và đặc biệt là dễ bảo trì hơn.  Kiến trúc module có khả năng tái sử dụng các thành phần của hệ thống và khả năng mở rộng tốt hơn.
  6. Kiến trúc module  Dựa trên quan điểm “chia để trị”  C: độ phức tạp C(p1 + p2) > C(p1) + C(p2)  E: nỗ lực thực hiện E(p1 + p2) > E(p1) + E(p2)  Giảm độ phức tạp  Cục bộ, dễ sửa đổi  Có khả năng phát triển song song  Dễ sửa đổi, dễ hiểu nên dễ tái sử dụng
  7. Kiến trúc module Phân rã phân mềm thành các module có thể nối kết với nhau
  8. Kiến trúc module  Kích thước module nên được quyết định dựa trên khái niệm độc lập chức năng, mỗi module thực hiện một công việc: dễ hiểu, dễ sửa đổi, dễ tái sử dụng
  9. Kiến trúc module Interface – công cụ giao tiếp của các module  Các module được gắn kết với nhau trong chương trình thông qua các "interface".  Một interface của module mô tả những thành phần được cung cấp và cần được cung cấp.  Các thành phần này được các module khác "thấy" và sử dụng.
  10. Kiến trúc module Nguyên tắc Information-hiding  Những phần có khả năng thay đổi bên trong của module được ẩn đi nên những phần còn lại dùng để giao tiếp giữa các module sẽ không bị ảnh hưởng khi thay đổi thiết kế.  Kết quả là những module có thể thay đổi một cách độc lập mà không ảnh hưởng lẫn nhau.
  11. Kiến trúc module  Kiến trúc module có thể mở rộng để áp dụng ở mức hệ thống và các module có thể là các ứng dụng hay dịch vụ chạy song song và tương tác với nhau thông qua một kiểu giao tiếp như Messaging, RPC, Socket...  Về ý tưởng, kiến trúc module có thể xem là nền tảng cơ bản của rất nhiều kiến trúc tiên tiến khác như MVC, Multi-tier, SOA...  Kiến trúc module có thể tái áp dụng vào các module của chính nó hay các thành phần con của các kiến trúc trên như các dịch vụ bên trong các hệ thống SOA..
  12. Kiến trúc module Kiến trúc Module mở rộng
  13. Tiêu chí đánh giá kiến trúc module  Coupling: mức độ ghép nối giữa các module  Cohesion: mức độ liên kết giữa các thành phần bên trong một module  Understandability: tính hiểu được  Adaptability: tính thích nghi được
  14. Tiêu chí đánh giá kiến trúc module  Coupling (ghép nối)  Độ đo sự liên kết (trao đổi) giữa các Module  Ghép nối chặt chẽ thì khó hiểu, khó sửa đổi do phải tính đến các liên kết có thể, dễ gây lỗi lan truyền.  Cohesion (kết dính)  Độ đo sự phụ thuộc lẫn nhau của các thành phần trong một Module  Kết dính cao thì tính cục bộ cao (độc lập ch ức năng); dễ hiểu, dễ sửa đổi. Tiêu chuẩn của thiết kế tốt: kết dính chặt, ghép nối lỏng
  15. Coupling (ghép nối) a. Ghép nối nội dung  Các module dùng dữ liệu hay thông tin điều khiển được duy trì trong một module khác  Là trường hợp xấu nhất. Ví dụ: Các ngôn ngữ bậc thấp chỉ dùng biến chung Lạm dụng lệnh Goto trong một chu trình
  16. Coupling (ghép nối) b. Ghép nối chung Các module trao đổi dữ liệu thông qua biến tổng thể  Lỗi của module này có thể ảnh hưởng đến hoạt động của module khác  Khó sử dụng lại các module
  17. Coupling (ghép nối) c. Ghép nối điều khiển Các module trao đổi thông tin điều khiển  Làm cho thiết kế khó hiểu, khó sửa đổi, dễ nhầm
  18. Coupling (ghép nối) d. Ghép nối nhãn  Các module trao đổi thừa thông tin  Module có thể thực hiện chức năng ngoài ý muốn  Làm giảm tính thích nghi
  19. Coupling (ghép nối) e. Ghép nối dữ liệu Truyền dữ liệu qua tham số  Nhận kết quả qua tham số và giá trị trả lại
  20. Lập trình theo module  Một số ngôn ngữ hỗ trợ lập trình theo cơ chế module cho phép biên dịch các module một cách độc lập và có thể gắn kết vào hệ thống lúc thực thi như Flex, Ruby...  Một số ngôn ngữ khác thì hỗ trợ cơ chế như thư viện liên kết động (DLL) để biên dịch các module thành các thư viện độc lập và có thể gắn kết động vào hệ thống.
ADSENSE

CÓ THỂ BẠN MUỐN DOWNLOAD

THÔNG TIN
TRỢ GIÚP
HỖ TRỢ KHÁCH HÀNG
Theo dõi chúng tôi

Chịu trách nhiệm nội dung:

Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA

LIÊN HỆ

Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM

Hotline: 093 303 0098

Email: support@tailieu.vn

Giấy phép Mạng Xã Hội số: 670/GP-BTTTT cấp ngày 30/11/2015 Copyright © 2022-2032 TaiLieu.VN. All rights reserved.

 

Đồng bộ tài khoản
2=>2