BÀI 1 LẬP TRÌNH, GHÉP NỐI CÁC CHƯƠNG TRÌNH
6.1. TỔ CHỨC LẬP TRÌNH VÀ GHÉP NỐI HỆ THỐNG
6.1.2. Các bước lập trình, ghép nối và chạy thử
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 đó. Q trình này được gọi là q trình thiết kế các module hay thiết kế mức dưới.
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à theo tác đủ rõ ràng và tường minh để có thể mã hố thơng qua một ngơn ngữ lập trình nào đó. Hơn nữa, mức độ chi tiết hố 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ư:
• 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 tn thủ.
• Nếu lập trình viên khơng tham gia trong q 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êts 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à số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ổ chhứ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à số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 q 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 100dịng mã lệnh thực hiện (khơng q 2 trang văn bản chương trình).
• 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 số 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ắng" 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 thhử đ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 đã hồ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 đã hồ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.
6.2. CÁC CƠNG CỤ TRỢ GIÚP LẬP TRÌNH VÀ CÀI ĐẶT
Các cơng cụ trợ giúp lập trình (Programing CASE Tools) nhằm trợ giúp các lập trình viên tự động hố trong một chừng mực nào đó các cơng đoạn trong q trình lập trình.
a. Ngơn ngữ lập trình:
Các ngơn ngữ lập trình và chương trình dịch đóng một vai trị rất quan trọng. Nếu các thành phần này khá đơn giản, hồn tồn thích hợp với các ứng dụng, lập trình viên có thể học rất nhanh, sử dụng thành thạo các cấu trúc lệnh và lập trình mà khơng cần tốn quá nhiều cơng sức. Hơn nữa, các chương trình dịch làm việc khá nhanh, các thông báo lỗi đầy đủ và rõ ràng.
Ngồi ra các chương trình dịch cịn phải đảm bảo các trình tiện ích sau:
b. Bộ soạn thảo
Đưa ra những dạng mẫu đối với các câu lệnh, người sử dụng chỉ cần điền thêm các biến.
Chẳng hạn, để trợ giúp lập trình bằng PASCAL, hệ soạn thảo đưa ra khn dạng sau:
FOR % {biến - điều khiển}% : = % {bthức} % {TO/DOWN TO}% % {bthức} % DO % {câu lệnh} %
END;
Người sử dụng chỉ cần điền vào các biến, các biểu thức và câu lệnh dưới sự trợ giúp của bộ soạn thảo. Bộ soạn thảo có thể gọi tới chương trình dịch. Nếu có lỗi khi dịch, bộ soạn thảo sẽ quay trở lại cùng với thơng báo lỗi tại dịng mã chương trình nguồn đã gây ra lỗi.
c. Bỗ gỡ lỗi
Nhằm giúp người lập trình phát hiện và sửa lỗi nhờ các can thiệp sâu vào quá trình thực hiện chương trình: dừng quá trình thực hiện, dõi vết và thực hiện từng bước các dịng lệnh. Các chương trình gỡ lỗi hiệu quả cịn cho phép tạo và hiển thị giá trị các biến ở bất kỳ một thời điểm nào.
d. Hệ quản lý mã chương trình nguồn (Code Management System) viết tắt là
QLCT
Hệ quản lý mã chương trình nguồn đơi lúc cịn được gọi là hệ quản lý cấu hình (Configuration Manager). Hệ quản lý dạng này có ý nghĩa to lớn trong q trình lập trình, nó lưu giữ tất cả các nguồn thơng tin về chương trình: ai cập nhật gì và những đụng độ khi có 2 người muốn cập nhật cùng một module nào đó. Hệ QLCT cịn cung cấp các cơng cụ để lưu giữ các thay đổi lên các module, phục hồi các phiên bản của nó.
Hệ QLCT có thể xử lý các tệp ASCII, do đó nó khơng chỉ hiệu quả khi dõi viết các chương trình nguồn, mà cịn dùng để lưu trữ các tệp tư liệu, các tệp dữ liệu kiểm thử ở dạng văn bản cũng như các tệp tạo dựng hệ thống. Chẳng hạn tại hãng sản xuất phần cứng, phần mềm DEC thường có 20-30 phiên bản hệ điều hành, mỗi hệ khác nhau một chút tuỳ thuộc vào hàng trăm những hoán đổi hay kết hợp các điểm mạnh về phần cứng và phần mềm. Thực tiễn chứng tỏ rằng các hệ QLCT đặc biệt cần thiết khi dõi vết tất cả các phiên bản của hệ thống chương trình.
e. Hệ quản lý các module (Module Management System), viết tắt là QLMĐ
Hệ quản lý các module thường được để tự động hố q trình dịch và kết nối, hay xây dựng hệ thống. Nó cho phép xây dựng lại những phần bị thay đổi tính từ lần đầu xây dựng gần nhất. Hệ QLMĐ còn dùng để chạy tự động một tệp các dữ liệu kiểm thử. Có thể thấy rằng hệ QLMĐ còn dùng để chạy tự động một tệp các phiên bản của hệ thống: ráp nối các chương trình nguồn, ảnh và tất cả những tư liệu trong một phiên bản. Hệ QLMĐ có thể làm việc phối hợp với hệ QLCT (tồn bộ các chương trình nguồn, tệp văn bản và tệp câu lệnh cần chạy hệ QLMĐ có thể lưu trữ lại).
f. Hệ quản lý các kiểm thử (Test Manager) viết tắt của QLKT
Hệ loại này được dùng để tự động hoá việc kiểm thử hệ thống. Để sử dụng hiệu quả hệ QLKT, phải xác định tệp các kiểm thử cần chạy cùng với các thông tin ra mong muốn. Hệ QLKT sẽ chạy với các dữ liệu kiểm thử và thơng báo cho lập trình viên nếu kết quả khác với kết quả mong muốn.