5.3.1. Yêu cầu
Tài liệu vào. Biểu đồ DFD của hệ thống con máy tính ở mức sâu nhất.
Cách tiến hành. Chuyển từ DFD thành lược đồ chương trình. Sử dụng các tiếp cận từ trên xuống, tinh chỉnh dần lược đồ chương trình từng bước để cuối cùng thu được một lược đồ chương trình hiệu quả thỏa mãn các yêu cầu về chất lượng.
Yêu cầu đối với lược đồ chương trình.
- Nhiệm vụ của mọi chức năng xử lý trong DFD phải được chuyển hết vào các module chương trình của lược đồ chương trình. Đó có thể là sự chuyển đổi mỗi chức năng xử lý thành một module chương trình., mà cũng có thể là sự phân tán hay tổ hợp các chức năng xử lý vào các module chương trình khác nhau.
- Phải thêm các module vào/ra, và đặc biệt là thêm các module điều khiển làm nhiệm vụ dẫn dắt quá quá trình xử lý. Trong số các module điều khiển đó phải có một module đặt ở gốc của lược đồ chương trình, thường gọi là module chính.
- Thiết lập các lời gọi (kèm theo các thông tin chuyển giao) giữa các module, phản ánh được quá trình thực thi của chương trình.
Ví dụ. Trong hệ thống Cung ứng vật tư, quá trình "Lập phiếu phát hàng" được diễn tả bằng DFD sau. Dự trù Dòng dự trù Giao hàng Dòng giao hàng Tìm địa chỉ phát hàng Làm phiếu phát hàng SHGH+SHMH Địa chỉ
Lược đồ chương trình ứng với DFD trên là
Cách làm như trên khá đơn giản, song lược đồ chương trình thu được thường là quá rườm rà. Vả lại, khi gặp một DFD có dạng phức tạp, thì việc chuyển nó thành lược đồ chương trình không phải là dễ như ví dụ trên.
Các dạng phức tạp thường thể hiện dưới hai dạng điển hình: Cấu trúc biến đổi và Cấu trúc giao tác. Do đó có hai hướng thiết kế khác nhau là thiết kế hướng biến đổi và thiết kế hướng giao tác.
5.3.2. Thiết kế hướng biến đổi
Thiết kế hướng biến đổi áp dụng cho trường hợp DFD có nhiệm vụ biến đổi một số thông tin lấy từ một số nguồn phát, thành một số thông tin gửi tới nơi nhận. Trong thiết kế hướng biến đổi xuất hiện khái niệm trung tâm biến đổi.
Trung tâm biến đổi: là trung tâm xử lý, biến đổi các thông tin vào để tạo ra luồng thông tin ra đi ra. Nó có thể là một đơn thể, có thể là một tập hợp các đơn thể.
Phát hàng Lấy SHGH và SHMH Tìm địa chỉ phát hàng In phiếu phát hàng Tìm SHĐH Tìm SHDT và SHPX Số hiệu mặt hàng Số hiệu giao hàng SHGH SHMH Số hiệu p.xưởng SHGH SHMH Số hiệu p.xưởng SHGH SHMH Số hiệu đơn hàng Số hiệu p.xưởng SHĐH SHMH
Luồng vào Luồng ra
Việc thiết kế hướng biến đổi nhằm phát hiện một trung tâm biến đổi thông tin chủ yếu.
Các bước thực hiện
Bước 1. Với luồng vào. Dõi theo các luồng dữ liệu vào và vượt qua các chức năng biến đổi thông tin sơ bộ cho đến khi hoặc các dữ liệu đó trở thành dữ liệu vào ở các dạng trừu tượng nhất, hoặc không còn xem chúng là dữ liệu vào nữa.
Bước 2. Với luồng ra. Với các dòng dữ liệu ra, đi ngược dòng vượt qua các chức năng biến đổi thông tin cho đến khi không xem đó là dữ liệu ra được nữa thì đánh dấu ngắt các luồng ra.
Bước 3. Căn cứ vào các điểm đánh dấu khoanh vùng các xử lý còn lại đấy là trung tâm biến đổi.
Ví dụ.
Bước 4. Vẽ hai mức cao nhất trong lược đồ chương trình. - Mức 1: Gồm các module chính
- Mức 2:
o Một module vào cho mỗi luồng dữ liệu vào
o Một module ra cho mỗi luồng dữ liệu
o Một module cho trung tâm biến đổi
Bước 5. Triển khai mỗi module ở mức 2 xuống mức thấp hơn và làm xuất hiện dần các module tương ứng với chức năng xử lý trong DFD.
Ví dụ E F G D B A H K C Nhận 1 Nhận 2 Nguồn 1 Nguồn 2 x1 x2 x3 y1 y2 q 2 q 1 q 3 q 4 s 1 s 2 s 3 s 4
5.3.3. Thiết kế hướng giao tác
Đặc trưng của cấu trúc giao tác là một chức năng phân loại cho phép xác định loại của dữ liệu vào, để rồi cứ mỗi loại sẽ cung cấp một cách xử lý riêng.
Thiết kế hướng giao tác áp dụng cho trường hợp DFD thể hiện một cấu trúc giao tác như vậy. Trong thiết kế giao tác xuất hiện khái niệm trung tâm giao tác
Trung tâm giao tác: là trung tâm xử lý luồng thông tin vào và tạo ra luồng thông tin ra. Tuy nhiên luồng thông tin vào trung tâm giao tác có tính giao tác tức là nó sẽ gây ra luồng dữ liệu đi ra theo một chiều trong nhiều nhánh khác nhau.
Các bước thực hiện
Chính
Vào Biến đổi Ra
D x3 y2 x3 y2 s1 s1 s2 s2 E F G y2 x3 q1 q2 q 2 s1 s2 q3 q4 q4 Vào A B C x1 y1 x1 x2 y2 y1 x3 H F Ra s1 s3 s4 s1 s2 x2
Giao diện Giao diện
Giao dịch
Nhánh 1
TRUNG TÂM GIAO TÁC
Nhánh 2
Bước 1. Xác định và khoanh vùng các trung tâm giao tác trong DFD
Bước 2. Xác định các loại giao tác khác nhau tương ứng với các luống ra của trung tâm giao tác đồng thời xác định các chức năng được khởi động từ trung tâm giao tác đó.
Bước 3. Vẽ lược đồ chương trình ở hai mức cao nhất - Mức 1: Một module chính
- Mức 2: Gồm 2 module, một module cho đầu vào giao tác và một module cho xử lý giao tác.
Bước 4. Triển khai các module mức 2 xuống mức thấp hơn, mỗi xử lý một module và được module xử lý giao tác gọi qua phép chọn. Khi khai triển cần phát hiện các module dùng chung E F G D B A H K C Nhận 1 Nhận 2 Nguồn 1 Nguồn 2 x1 x2 x3 y1 y2 q2 q1 q3 s1 s2 s3 r2
Trung tâm giao tác
Nhận 2 r1 Chính Vào Xử lý giao tác E x3 y2 s1 s2 H Ra1 y2 x3 q1 q1 q2 q3 Vào A B C x1 y1 x1 x2 y2 y1 x3 x2 Giao diện Giao diện XL1 XL2 XL3 G K Ra2 y2 x3 s1 s1 s2 s3 F Ra3 y2 x3 r1 r2 Giao diện Giao diện y2 x3 x3 y2
5.4. THIẾT KẾ CÁC MẪU THỬ
Mẫu thử có thể được phát sinh ngẫu nhiên hoặc không ngẫu nhiên, tự động hoặc không tự động.
Cách thử chương trình bằng mẫu thử: Thử tính đúng đắn
So kết quả thu được với kết quả chờ đợi
Nếu trong quá trình thử phức tạp, yêu cầu chương trình in các giá trị trung gian
Kiểm tra giá trị trung gian Kiểm tra vệt chương trình
Thử hiệu năng: các mẫu thử phải đủ lớn và có thể thử nghiệm trong một thời gian dài.
CHƯƠNG 6 – LẬP TRÌNH CHẠY THỬ VÀ BẢO TRÌ 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.1. Các công việc chuẩn bị trước khi tiến hành lập trình
Trước khi bắt tay vào giai đoạn lập trình, các chuyên gia quản lý dự án phải trả lời các câu hỏi sau:
• Kết quả rà xét lại thiết kế có yêu cầu phải làm lại một phần nào đó trong hệ thống không? Nếu có, phải sắp xếp thời gian một cách phù hợp và không nên bắt đầu lập trình khi chưa giải quyết ổn thoả mọi chuyện.
• Các nguồn nhân lực, vật lực và thông tin, cũng như là các lập trình viên lúc nào cũng sẵn sàng và dự an sẽ kết thúc đúng theo kỳ hạn. Khi có thay đổi nhân sự vì bất cứ lý do gì, cần phải lượng trình năng suất công việc của người mới đến thay thế để có thể trù liệu trước mọi chuyện đáp ứng được hạn định đã đặt ra. Bởi lẽ trong các công ty với các điều kiện làm việc như nhau, một chuyên gia lập trình giỏi có thể làm việc với năng suất gấp 8 lần người có trình độ trung bình.
• Mọi người đã được đào tạo chưa? Chẳng hạn, khi bắt tay vào công việc, các lập trình viên phải biết rõ về hệ điều hành, ngôn ngữ lập trình và các công cụ lập trình sẽ được sử dụng. Họ còn phải làm quen với ứng dụng mà người sử dụng đặt hàng cũng như bài toán cần giải quyết. Một điều quan trọng là phải cung cấp tài liệu đầy đủ đề các lập trình viên biết rõ về tài liệu yêu cầu và đặt tả chức năng.
• Mô trường lập trình dành cho các thành viên trong dự án đó được chuẩn bị tốt, đáp ứng các yêu cầu của công việc không? Kinh nghiệm triển khai thực tiễn đã chứng tỏ rằng nên chọn những phần mềm và công cụ lập trình dễ sử dụng. Các máy tính dùng để phát triển công việc của dự án phải đáp ứng được yêu cầu: trả lời nhanh (tốc độ cao), dung lượng bộ nhớ đủ lớn, có độ tin cậy cao và cung cấp đủ khi cần thiết. Một điểm quan trọng khác là phải đảm bảo các thiết bị vẫn đang được nhà sản xuất bảo hành, các tài liệu về phần mềm phát triển vẫn đang được cập nhật thường xuyên. Trong thời gian thực hiện dự án phải luôn đảm bảo hệ thống không bị gián đoạn.
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 đó. 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.
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ã 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ư:
• 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ê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à 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ổ 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à 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 100dòng mã lệnh thực hiện (không quá 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 đã 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