Phân tích thiết kế hệ thống - Thiết kế chương trình

Nội dung text: Phân tích thiết kế hệ thống - Thiết kế chương trình

1. Phân tích và thiết kế hệ thống System Analysis & Design Bài giảng 7: THIẾT KẾ CHƢƠNG TRÌNH TS Đào Nam Anh 1
2. Tham khảo • Systems Analysis and Design, Alan Dennis and Barbara Haley Wixom Fred Niederman John Wiley & Sons, Inc. • Dao Nam Anh, "Systems Analysis And Design", Course Book, University of Power, 201 2
3. Nội dung Chương 7. Thiết kế chương trình 7.1 Có cấu trúc hay không cấu trúc 7.2 Thiết kế cấu trúc 7.3 Lập lược đồ chương trình 3
4. Giới thiệu Các kết quả thu được qua các giai đoạn phân tích, thiết kế tổng thể và thiết kế chi tiết (về giao diện, và cơ sở dữ liệu) dù là khá phong phú nhưng vẫn còn là chưa đủ để có thể chuyển sang lập trình được. 4
5. Giới thiệu Các yếu tố còn thiếu là: 1. Các chức năng xuất hiện trong các mô hình luồng dữ liệu (DFD) chỉ là các chức năng logic (thuộc lĩnh vực bài toán) mà chưa có các chức năng phù trợ cần thiết như là các chức năng đối thoại với người dùng, xử lý lỗi, xử lý đầu vào, đầu ra, tra cứu CSDL và các chức năng điều hành liên kết các chức năng khác. 2. Các liên quan giữa các chức năng trong DFD chỉ là các chuyển giao dữ liệu mà không phải là chuyển giao điều khiển (tức là chuyển giao sự thực hiện khi thi hành). Một đặc trưng không thể thiếu trong một chương trình là đặc trưng điều khiển (sự tuần tự, chọn, lặp và đặc biệt là lời gọi giữa các chương trình con). Đặc trưng 5 này chưa hề có trong các DFD.
6. Giới thiệu • Vì các thiếu sót này mà các DFD thu được từ giai đoạn phân tích còn phải được biến đổi, bổ sung thêm chi tiết thì mới trở thành đầu vào thực sự cho việc lập trình được. Vì vậy phải có thêm một giai đoạn thiết kế chi tiết, đó là thiết kế chương trình. Đây cũng chỉ là một giai đoạn của thiết kế, nhằm đưa ra các quyết định về cài đặt, chứ chưa phải là cài đặt, chưa phải là lập trình thực sự. 6
7. Giới thiệu • Kết quả của việc thiết kế chương trình là các lược đồ chương trình (cấu trúc các module), với đặc tả nội dung của từng module trong lược đồ chương trình, và các mẫu chương trình thử nghiệm. • Thiết kế chương trình theo hướng nào để hiệu quả? Liên quan đế câu hỏi này là thiết kế có cấu trúc hay không cấu trúc. Dưới đây là phân tích về sự lựa chọn hướng thiết kế cấu trúc và các phương pháp thiết kế. 7
8. Có cấu trúc hay không cấu trúc • Lập trình có cấu trúc là một kỹ thuật tiêu chuẩn được sử dụng để phát triển phần mềm. Lập trình cấu trúc được phát minh để giải quyết những thiếu sót của chương trình không có cấu trúc, dạng thường xuyên sử dụng câu lệnh GO TO để di chuyển từ chỗ này sang chỗ khác của chương trình. Sử dụng GO TO, người ta có thể chuyển về trước, về sau, hoặc bất cứ nơi nào trong chương trình. 8
9. Có cấu trúc hay không cấu trúc • Trong chương trình có sử dụng GO TO, các kết nối giữa các bộ phận của trở nên khá lộn xộn. Sự lộn xộn và đôi khi phức tạp của các mối liên kết giữa các bộ phận của chương trình giống như mỳ spaghetti. Loại của chương trình này khó hiểu và khó gỡ lỗi. Lập trình không cấu được xem như là một chiến lược kém hiệu quả. 9
10. Có cấu trúc hay không cấu trúc • Lập trình có cấu trúc là sử dụng các cấu trúc điều khiển (lựa chọn IF-THEN, SELECT CASE và vòng lặp) mà không không sử dụng lệnh GO TO, • Nguyên tắc thực hiện tuần tự có nghĩa là các lệnh phải được thực hiện theo thứ tự mà chúng xuất hiện. • Nguyên tắc lựa chọn có nghĩa là tùy theo điều kiện mà thực hiện lệnh tại nhánh THEN hoặc nhánh ELSE. Lựa chọn SELECT CASE cho phép chia làm nhiều hướng thực hiện tùy theo điều kiện. • Vòng lặp là REPEAT-UNTIL hoặc WHILE-END hoặc FOR-DO-END. 10
11. Có cấu trúc hay không cấu trúc • 11
12. Thiết kế cấu trúc • Phần này sẽ giới thiệu một số phương pháp thiết kế cấu trúc bằng cách chia nhỏ một chương trình thành các phần con được gọi là các module. Mỗi module là một bộ độc lập các mã lệnh. Module cũng được gọi là thủ tục, hoặc chương trình con. Ưu điểm của lập trình module là khả năng viết và kiểm tra mỗi module độc lập và trong một số trường hợp có thể tái sử dụng module trong các chương trình khác. Một chương trình bao gồm nhiều module. Ngoài ra, một module chính có thể gọi các module khác. 12
13. Thiết kế cấu trúc Các phương pháp sau đây dùng để thiết kế một chương trình bao gồm các module. • Thiết kế từ trên xuống (top-down) hoặc • Thiết kế từ dưới lên (bottom-up) • Thiết kế mịn dần 13
14. Thiết kế cấu trúc Thiết kế từ trên xuống • Một lập trình phương pháp đã được chứng minh là hiệu quả nhất được gọi là phân rã từ trên xuống. Phân rã từ trên xuống là quá trình chia nhỏ các thủ tục lớn thành các vào các phận nhỏ hơn (module) và cứ chia nhỏ tiếp đến khi đã đạt tới mức chi tiết thấp nhất. • Sử dụng phương pháp này, một vấn đề phức tạp được tách thành các phần đơn giản, có thể được lập trình dễ dàng. Trong mỗi giai đoạn, các mã lệnh hoặc các thủ tục có thể được kiểm tra các lỗi logic, sửa chữa hoặc thay đổi mà không ảnh hưởng tới các chương trình con khác. Kết quả sẽ là một chương trình với các module đáp ứng yêu cầu “có thể được sửa đổi một cách dễ dàng". 14
15. Thiết kế cấu trúc Thiết kế từ trên xuống • Chiến lược lập trình này tập trung vào phát triển một kiến trúc chương trình trước khi viết lệnh. Kết quả là một sơ đồ trông giống như một sơ đồ tổ chức với các module chính tại các module trên và nối xuống dưới các module cấp dưới. Biểu đồ cho các module liên quan đến nhau nhưng không mô tả chi tiết chương trình trong mỗi module. Biểu đồ cấu trúc này được gọi là Tổ chức Chương trình Cấu trúc (Hierarchical Program Organisation - HIPO) 15
16. Thiết kế cấu trúc Thiết kế từ trên xuống • Các nhiệm vụ đưa ra ở trên có thể được mô tả trong một biểu đồ phân cấp (HIPO) 16
17. Thiết kế cấu trúc Thiết kế từ trên xuống • Xác định và biểu diễn mối quan hệ giữa các module trong bài toán này cho phép lập trình viên tập trung vào tổ chức tổng thể và logic của chương trình mà không bị sa lầy trong các chi tiết. Một khi cấu trúc tổng thể của chương trình được hoàn thiện, có thể tiến hành mã hóa chi tiết của từng module. 17
18. Thiết kế cấu trúc 7.2.2 Thiết kế từ dƣới lên • Trong chiến lược thiết kế từ dưới lên, ta lấy các chương trình đã có sẵn để tạo nên các module bậc cao hơn. Như vậy là sử dụng các thiết kế hiện có để tạo ra một chương trình có hiệu quả tốt hơn 18
19. Thiết kế cấu trúc 7.2.2 Thiết kế từ dƣới lên 19
20. Thiết kế cấu trúc 7.2.3 Thiết kế mịn dần • Thiết kế từng bước mịn dần là một chiến lược thiết kế từ trên xuống. Chương trình được phát triển bằng cách liên tục làm tăng dần mức độ chi tiết của các thủ tục. • Trong mỗi bước làm mịn, một số các lệnh của các chương trình này được phân tách thành các lệnh chi tiết hơn. • Quá trình mịn dần kết thúc khi tất cả các mã lệnh được thể hiện trong các thư viện lệnh có sẵn hoặc có trong ngôn ngữ lập trình. Mỗi bước làm mịn là các quyết định thiết kế. Điều quan trọng là lập trình viên phải biết các tiêu chí cơ bản của dự án. 20
21. Lập lƣợc đồ chƣơng trình • Lược đồ chương trình còn gọi là lược đồ cấu trúc là một biểu diễn dưới dạng đồ thị của một tập hợp các module cùng với các giao diện giữa các module đó, bao gồm sự chuyển giao điều khiển và chuyển giao dữ liệu 21
22. Lập lƣợc đồ chƣơng trình Module chương trình • Định nghĩa: trong định nghĩa lược đồ cấu trúc thì module được hiểu là một chương trình con hoặc một cụm câu lệnh nằm trong chương trình hay trong một số ngôn ngữ lập trình có các UNIT, CLASS, OBJECT thì đây thực chất là các nhóm module chương trình tập hợp xung quanh một cấu trúc dữ liệu. 22
23. Lập lƣợc đồ chƣơng trình Module chương trình Các thuộc tính cơ bản của module: • Thông tin vào, ra: thông tin nhận được từ chương trình gọi nó hoặc thông tin trả lại cho chương trình gọi nó. • Chức năng hàm biến đổi từ đầu vào thành đầu ra. • Phương thức để thực hiện chức năng trên. • Dữ liệu cục bộ: các bộ nhớ hay cấu trúc dữ liệu dùng riêng cho module. 23
24. Lập lƣợc đồ chƣơng trình Công cụ để diễn tả Lược đồ chương trình – Biểu diễn các module • Module được biểu diễn bằng một hình chữ nhật trên có ghi nhãn là tên module. Trường hợp module được định nghĩa sẵn trong hệ thống hay trong thư viện chương trình thì các cạnh bên được vẽ nét đôi. Tên module Module có sẵn 24
25. Lập lƣợc đồ chƣơng trình Công cụ để diễn tả Lược đồ chương trình – Kết nối các module • Các module có thể được kết nối với nhau bằng các lời gọi, diễn tả bởi một đường liên kết có hướng. • Module A gọi module B với các dữ liệu đầu vào. • Module B thực hiện và trả lại kết quả cho module A A B 25
26. Lập lƣợc đồ chƣơng trình Công cụ để diễn tả Lược đồ chương trình – Kết nối các module Module A gọi lặp module E và F A E F 26
27. Lập lƣợc đồ chƣơng trình Công cụ để diễn tả Lược đồ chương trình – Kết nối các module Thứ tự thực hiện từ trái sang phải A B C D E F 27
28. Lập lƣợc đồ chƣơng trình Công cụ để diễn tả Lược đồ chương trình Thông tin trao đổi giữa các module • Các thông tin được gửi kèm với lời gọi (các tham số) và thông tin trả về sau khi thực hiện lời gọi được thể hiện bằng các mũi tên nhỏ vẽ dọc theo cung biểu diễn cho lời gọi, có kèm theo tên của thông tin. Một ví dụ tính lương: Tính lương Lương chính Ngày công Lương phụ Lương chính Loại phụ cấp Phụ cấp Tính lương Tính phụ Lên bảng 28 chính cấp lương
29. Lập lƣợc đồ chƣơng trình Công cụ để diễn tả Lược đồ chương trình Chất lƣợng của Lƣợc đồ chƣơng trình • Ta chưa nên xem xét lược đồ chương trình mới được lập là phiên bản cuối cùng mà chỉ coi đây là phác thảo thiết kế module. Ta cần tiếp tục tinh chỉnh nó bằng cách gộp, tách hay san sẻ lại nhiệm vụ giữa các module để đạt được các tiêu chuẩn về chất lượng sau 29
30. Lập lƣợc đồ chƣơng trình Công cụ để diễn tả Lược đồ chương trình • Sự tƣơng liên. Sự tương liên là mức độ ảnh hưởng lẫn nhau giữa các module. Một lược đồ chương trình tốt thì sự tương liên càng phải lỏng, càng phải đơn giản. 30
31. Lập lƣợc đồ chƣơng trình Công cụ để diễn tả Lược đồ chương trình Các loại tương liên: • Tương liên về nội dung: ví dụ một module làm thay đổi nội dung (các lệnh) của module khác, rẽ nhánh sang một module khác hay sử dụng dữ liệu của module được gọi. Cần loại bỏ tương liên này. • Tương liên về điều khiển: là trường hợp một module này chuyển điều khiển cho một module khác. Tương liên điều khiển vi phạm nguyên tắc che giấu thông tin. Vì vậy tương liên điều khiển cũng nên tránh. • Tương liên về dữ liệu: đó là trường hợp hai module trao đổi dữ liệu cho nhau. Sự trao đổi dữ liệu càng đơn giản càng tốt. 31
32. Lập lƣợc đồ chƣơng trình Công cụ để diễn tả Lược đồ chương trình • Sự cố kết. Là sự gắn bó giữa các phần bên trong của một module. Module càng cố kết thì chức năng của nó càng dễ thấy, logic do đó dễ phát hiện lỗi, dễ bảo trì. 32
33. Lập lƣợc đồ chƣơng trình Công cụ để diễn tả Lược đồ chương trình • Hình thái. Phạm vi điều khiển của một module là phần lược đồ chương trình bao gồm module đó và những module phụ thuộc (được gọi) trực tiếp hay gián tiếp từ nó. Phạm vi ảnh hưởng của một quyết định là mọi module nằm trong lược đồ chương trình, và chịu ảnh hưởng của quyết định đó. Một lược đồ chương trình tốt thì về mặt hình thái: Các quyết định có miền ảnh hưởng càng hẹp càng tốt. Mỗi phạm vi ảnh hưởng nằm trong phạm vi điều khiển tương ứng. 33
34. Lập lƣợc đồ chƣơng trình Công cụ để diễn tả Lược đồ chương trình • Module A gọi module B, C. Khi đó phạm vi ảnh hưởng của A là B và C. A B C 34
35. Lập lƣợc đồ chƣơng trình Công cụ để diễn tả Lược đồ chương trình • Khi B có quyết định Q, các module A, E, F có sử dụng quyết định Q. • Vậy miền ảnh hưởng của quyết định Q chính là A, E, F O A D B C E F 35
36. Lập lƣợc đồ chƣơng trình Đặc tả các module Sau khi lập được lược đồ chương trình cho mỗi hệ thống con, ta phải đặc tả mỗi module trong đó, tức là miêu tả rõ nội dung của module. Đặc tả một module ta cần nêu rõ: • Thông tin đầu vào (Input), thông tin đầu ra (Output) • Các thao tác thực hiện trong chương trình: các đối thoại với người dùng, các xử lý lỗi, tra cứu CSDL, các xử lý, • Các dữ liệu cục bộ của module 36
37. Lập lƣợc đồ chƣơng trình Đóng gói thành module tải Kết hợp các module hợp thành một module tải thì tiết kiệm bộ nhớ nhưng chi phí thời gian tải chương trình sẽ nhiều hơn. Vì vậy chúng ta cần cắt lược đồ chương trình thành các module tải hợp lý. Thiết kế module tải phải căn cứ vào các yếu tố như: • Kích cỡ bộ nhớ, • Kích cỡ các module, • Tần suất lần gọi module, • Trong module tải, các module phải gắn kết với nhau. 37
38. TÓM TẮT Chương 7. Thiết kế chương trình 7.1 Có cấu trúc hay không cấu trúc 7.2 Thiết kế cấu trúc 7.3 Lập lược đồ chương trình 38
39. Questions areanalysisanddesign 39