Phần I Chu trình dự án và quản lý theo giai đoạn
Chương 5. Giai đoạn thực hiện
5.2 Tổ chức lập trình các module cơ bản; ghép nối hệ thống
5.2.3 Các bước lập trình
Bước 1. Đặt kế hoạch tích hợp và kiểm thử hệ thống:
Kinh nghiệm xây dựng các hệ tin học cỡ lớn chỉ ra rằng không nên và không thể xây dựng một chương trình giải quyết được tất cả mọi việc. Trong những trường hợp như vậy, cách làm phân chia hệ thống thành các module nhỏ hơn thường tỏ ra hợp lý. Sau đó người ta tiến hành ráp nối các module một cách nhịp nhàng. Các nhà quản lý dự án phải đặt kế hoạch một cách rõ ràng, đưa ra thứ tự ghép nối các module sẽ được lập trình theo thứ tự tích hợp vào hệ thống. Kế hoạch này được gọi là kế hoạch kiểm thử hệ thống.
Các bước sau đây (bước 2 ÷ bước 9) chỉ liên quan tới một module của hệ thống mà thôi.
Bước 2. Thiết kế các module
Ở bước này, các lập trình viên nhận bản đặc tả thiết kế được bàn giao lại từ giai đoạn thiết kế (do kết quả của việc thiết kế mức tổng thể và mức trung gian).
Công việc ở đây là tiếp tục chia nhỏ thành các mức thấp hơn cho đến khi đạt tới các công việc “sơ cấp” theo nghĩa có thể lập trình được ngay bằng một ngôn ngữ lập trình nào đó. Quá trình này được gọi là quá trình thiết kế các module hay thiết kế mức dưới.
Ví dụ: Lập trình viên nhận được từ giai đoạn thiết kế sơ đồ ở mức trung gian như sau:
Hình vẽ 5.1 Sơ đồ thiết kế mức 3
Lập trình viên còn nhận được từ giai đoạn thiết kế mô tả về module như sau:
Lỗi/ trợ giúp Thông
báo lỗi/
trợ giúp Di
chuyển con trỏ
Lỗi Lỗi Thực
đơn con
Thu nhập
Sửa đổi Báo cáo Bắt đầu
AMST0000
Menu AMM00000
Bấm chuột AMC0000 Kéo - nhả
AMDR0000 Hành động
AMA0000 Lỗi
AME0000
Tên module: AMST0000 Gọi bởi: AM000000
Các chương trình con được gọi đến: <danh sách chương trình con>
Các tham số vào: không Hiển thị: không
Các tham số trở lại: Nếu không có lỗi đưa ra mã 0. Nếu có lỗi, đưa ra mã số của lỗi.
Các biến ngoài đước sử dụng: <danh sách biến>
Các tệp được sử dụng: STUDENT.DAT (open), COURSE.DAT (open), MATERIAL.DAT (open), SYSTEM.DAT (open), Các chức năng:
+ Mở Tệp STUDENT.DAT, COURSE.DAT, MATERIAL.DAT,
SYSTEM.DAT. Nếu có lỗi, đưa ra các mã lỗi.
+ Khởi tạo biến
+ Kiểm tra xem có bị sự cố tắt máy thông qua bản ghi 1 trong tệp SYSTEM.DAT
Byte 1 = -1 nghĩa là tắt máy đúng, nếu khác - 1 làm những việc sau...
+ Bảo đảm trạng thái chính của - Chuột nhờ kiểm tra....
Nếu có lỗi...
- Màn hình nhờ kiểm tra...
Nếu có lỗi ....
- Mang nhờ kiểm tra....
- Nếu có lỗi....
-
+ Mã lỗi thoát hệ thống bình thường là 0.
Lập trình viên đầu tiên vẽ sơ đồ cấu trúc của module như sau:
Hình vẽ 5.2. Chia nhỏ module ở mức 4 AMST0000
(Khởi tạo hệ thống) Vào - Thoát
Kiểm tra trạng thái tắt hệ thống
Mở tệp Mở tệp Khởi tạo
biến
Thiết kế module được tiến hành từ trên xuống dưới, bắt đầu từ ô trên cùng AMST0000 và chia nhỏ nó thành các phần con thích hợp như trên hình vẽ 5.3
1.1.1 1.1.2. 1.1.3. 1.1.4.
1.1.5 1.1.6
Hình vẽ 5.3. Chia nhỏ module ở mức 5
Tiếp sau đó, mỗi thành phần lại được chia nhỏ như trên hình vẽ 5.4 1.1.1
Hình vẽ 5.4. chia nhỏ module ở mức 6
Quá trình cứ tiếp tục như vậy cho đến một mức đủ chi tiết để các thành phần có thể lập trình được.
Câu hỏi đặt ra. Quá trình thiết kế hệ thống sẽ dừng lại ở mức chi tiết như thế nào và khi nào bắt tay vào thiết kế chi tiết từng module?
Câu trả lời. Quá trình thiết kế hệ thống nhằm chia nhỏ các module tới mức người lập trình có thể bắt đầu công việc của mình nghĩa là các đặc tả về dữ liệu và thao tác đủ rõ ràng và tường minh để có thể mã hoá thông qua một ngôn ngữ lập trình nào đó. Hơn nữa, mức độ chi tiết hoá tuỳ thuộc vào từng dự án một hay từng phần trong hệ thống, thậm chí cả quan niệm của người lập trình đảm nhận phần việc được giao.
Cần phải xem xét các yếu tố như:
AMST0000
AMSTSHC K
AMSTMENU
AMSTHWCK AMSTOPFI AMSTiNva
AMSTERRO
AMSTSHCK
AMSTSHOP AMTSHW
M
AMSTSHCD
• Nếu chia nhỏ các module là yêu cầu cấp thiết nhằm đáp ứng các đặc tính có độ ưu tiên cao như thời gian trả lời, giao diện hệ thống thân thiện cũng như tính tương hợp trong quá trình xử lý, thì người thiết kế có thể làm tới mức chi tiết sâu hơn.
• Mức độ chi tiết trong thiết kế có thể được ghi lại trong hợp đồng. Các dự án tầm cỡ cơ quan chính phủ, các Bộ, Ngành thường quy định rõ số mức thiết kế cần phải tuân thủ.
• Nếu lập trình viên không tham gia trong quá trình thiết kế, nên giả định là các thiết kế đó nhằm phục vụ cho các lập trình viên ở trình độ trung bình tức là làm rõ các chi tiết tới mức một lập trình viên hạng trung có thể hiểu và cài đặt được theo ý đồ thiết kế.
Chú ý: Cần phải nhấn mạnh rằng các lập trình viên thường không thích nhận được bản thiết kế quá chi tiết tới mức lập trình chỉ còn là phát biểu lại hay dịch các mệnh đề tiếng Anh sang một ngôn ngữ lập trình nào đó.
Bước 3: Rà soát thiết kế module
Cũng như đối với các thiết kế ở mức trên và mức giữa, cần phải cân nhắc các điểm lợi/hại khi tiến hành thiết kế ở các mức dưới. Do vậy cần phải rà soát lại thiết kế của từng module trước khi lập trình. Công việc này nên tổ chức gọn nhẹ.
Chỉ cần bản thân lập trình viên, người phụ trách trực tiếp và có thể là một lập trình viên cùng tham dự. Mục đích của việc rà soát lại thiết kế module là đảm bảo rằng đưa ra được một thiết kế tốt nhất có thể có được sao cho mọi chức năng đã được đề cập đến và tất cả mọi trục trặc đã được lường trước.
Bước 4: Đặt kế hoạch kiểm thử module
Lập trình viên phải lập kế hoạch kiểm thử module và dữ liệu trước khi bắt tay vào lập trình. Kế hoạch kiểm thử sau khi lập trình phải được xem xét. Trong kế hoạch này chỉ cần tập trung vào những “kiểm thử” đối với các phần khó nhất trong hệ thống. Người phụ trách dự án có thể tham gia rà soát kế hoạch kiểm thử cùng với rà soát thiết kế module. Theo kinh nghiệm, nên kết hợp 2 khâu này cùng một lúc.
Bước 5: Lập trình các module
Các tiêu chuẩn, các đòi hỏi đối với quá trình lập trình đã được trình bầy rõ trong giai đoạn thiết kế hệ thống (xem phần tài liệu kỹ thuật).
Các cách tiếp cận khác nhau trong triển khai lập trình:
• Cách tiếp cận cấu trúc
• Cách tiếp cận hướng đối tượng
Các tư tưởng lớn trong lập trình có cấu trúc là:
• Phân chia các công việc thành các module nhỏ. Mỗi module đảm nhận 1 chức năng riêng biệt nào đó, khoảng 100 dòng mã lệnh thực hiện (không quá 2 trang văn bản chương trình).
• Chỉ có một tham số vào, một tham số ra
• Càng ít biến tổng thể càng tốt
• Các lệnh cầu trúc được dùng là: tuần tự, if... then... else, case..., while... do..., repeat...until..., call....Tránh dùng lệnh go to.
Bước 6: Kiểm thử module:
Lập trình viên tiến hành kiểm thử module sau khi chọn một phạm vi bài toán phù hợp với cùng một ó liệu thử - thông tin vào sao cho quá trình thực hiện phải đi qua các nhánh xử lý chính trong module và quan sát kết quả nhận được.
Kinh nghiệm thực tế cho thấy nên tổ chức kiểm thử module theo giai đoạn.
Giai đoạn 1 gọi là kiểm thử “hộp trắmg” theo nghĩa người lập trình biết rõ cái gì diễn ra bên trong module và đưa ra các dữ liệu kiểm thử đi qua tất cả các nhành lôgic trong chương trình. Giai đoạn 2 là kiểm thử “hộp đen”. Người lập trình bỏ qua mà không cần biết nội bộ của module, các dữ liệu kiểm thử được đưa ra theo trình tự và tần xuất như trong sử dụng thực tế.
Ở giai đoạn này, cần phải chú ý và tránh được những lỗi đơn giản nhất (chẳng hạn lỗi gõ sai phím, lỗi sử dụng chuột,...).
Bước 7: Kiểm thử các mức tích hợp thấp nhất:
Nếu như một module nào đó gọi tới một vài module khác, thì lập trình viên có thể tích hợp chúng lại ngay sau khi đã hoàn tất công việc với từng module và tiến hành kiểm thử tất cả các module khi chúng phối hợp làm việc với nhau. Ngay cả khi lập trình viên không phải là người viết các module con này, anh ta vẫn phải kiểm thử các lỗi gọi tới chúng và kết quả trả lại. Cách tốt nhất để làm là tạo ra các
“cuống chương trình” (program stub) thay cho việc sử dụng thực tế module này.
Một cuống chương trình chỉ gồm 4 dòng lệnh, nhằm mô tả đã nhận được tín hiệu điều khiển từ chương trình mẹ, đưa ra các tham số nhận được, và chuyền điều khiển lên mức trên cùng với một số tham số ra (nếu cần thiết).
Bước 8: Lưu giữ các kết quả kiểm thử. Đệ trình các module đã hoàn tất để tích hợp.
Các kết quả kiểm thử module còn được dùng về sau để xây dựng các thống kê về lỗi, nguyên nhân và chi phí để sửa. Người phụ trách dự án phải chịu trách nhiệm tích hợp các module khi các hệ thống thông tin cần xây dựng thuộc loại cỡ nhỏ và trung bình. Để trợ giúp công việc quản lý, có thể sử dụng phần mềm quản lý mã chương trình (Code Management System) nhằm quản lý cấu hình, lưu giữ các thông tin về các phiên bản, những thay đổi lên mã chương trình nguồn (có thể xem phần nói về các công cụ trợ giúp công nghệ phần mềm – Computer Aided Software Engineering (CASE).
Bước 9: Bắt tay vào soạn thảo tài liệu cho người sử dụng
Có thể tổ chức biên soạn các tài liệu cho người sử dụng ngay sau khi hoàn tất kiểm thử module, độc lập với chuyện lập trình viên có tham gia trực tiếp trong nhóm biên soạn hay không.
Các tài liệu cho người sử dụng bao gồm:
1/ Tài liệu hướng dẫn sử dụng: Tài liệu này có thể do người lập trình, hay một chuyên viên kỹ thuật, thậm chí là người sử dụng biên soạn. Cần phải nhắc lại là các đặc tả chức năng trong giai đoạn phân tích, thiết kế đã phải có những mô tả chi tiết về các thực đơn, bố trí màn hình, các trình bày và những giao diện khác. Trong tài liệu này không nên trình bày dông dài. Để có một tài liệu hướng dẫn sử dụng tốt, nên chia thành các phần phù hợp với từng đối tượng người sử dụng có chuyên môn khác nhau. Tài liệu phải trình bày theo trình tự người sử dụng sẽ vận hành, khai thác hệ thống, bởi lẽ nó sẽ thuận tiện cho người sử dụng làm việc với hệ. Một thứ tự trình bày hay được sử dụng trong các tài liệu là thứ tự logic các chức năng trong cây thực đơn câu lệnh từ trên xuống dưới, từ trái sang phải, ở cuối tài liệu nên có phần tra cứu nhanh các lệnh, các thực đơn, và các thông báo theo thứ tự từ điển.
2/ Tài liệu hướng dẫn bảo trì: Một trong những yêu cầu cơ bản đối với công việc quản lý trong giai đoạn này là tổ chức để các lập trình viên biên soạn tài liệu chi tiết về chương trình để bảo trì hệ thống về sau. Phần lớn các chuyên gia quản lý dự án cho rằng tổ chức soạn thảo tài liệu hướng dẫn bảo trì không phải là công việc đơn giản. Bởi lẽ các lập trình viên thường không thích biên soạn tài liệu về chương trình, tốt nhất để họ viết sau khi mọi chuyện đã hoàn tất. Vả lại, các lập trình viên thường nghĩ rằng người bảo trì hệ thống lại đòi hỏi giải thích quá chi tiết về logic chương trình, nên xem rằng đây là công việc buồn tẻ và hoàn toàn không cần thiết.
Thật là khó trong những tình huống như vậy.
Một giải pháp đơn giản là có thể dùng đặc tả thiết kế ở mức module chi tiết và đầy đủ cùng với bản mã chương trình nguồn có chú giải đầy đủ khi bảo trì hệ thống.
Do vậy, tài liệu hướng dẫn bảo trì hệ thống phải gộp cả phần đặc tả thiết kế, listing chương trình và giải thích cách ghép nối, xử lý các thay đổi áp lên chương trình cũng như kết quả kiểm thử các module.
3/ Tài liệu khai thác và quản lý hệ thống
Tài liệu này giống như tài liệu hướng dẫn sử dụng, nhưng đây dành cho các nhân viên chịu trách nhiệm bật máy, sao lưu và xử lý các sự cố chủ yếu, lập các thống kê. Thường là các tài liệu cho các hãng sản xuất phần cứng và hệ điều hành đã khá đầy đủ, nên chỉ những thủ tục cần thiết để thích nghi phần mềm với từng nhu cầu cụ thể mới phải liệt kê ra.
4/ Tài liệu đào tạo: Nếu phải tổ chức khoá học về khai thác, sử dụng hệ thống, phải trù tính xem dạng tài liệu đào tạo nào cần phải biên soạn. Tài liệu hướng dẫn sử dụng nếu được biên soạn kỹ càng có thể dùng làm cơ sở cho tài liệu học. Tuy vậy, để việc đào tạo có hiệu quả, cần phải tạo ra những công cụ trợ giúp khác như các bản chiếu, các bài tập soạn sẵn,...
Vấn đề bản quyền: Cần phải chỉ rõ trên sản phẩm và các tài liệu cung cấp cho người sử dụng bản quyền của sản phẩm.