Hầu hết các bài toán ứng dụng trong thế giới thực đều phức tạp và do đó cấu trúc của hệ thống trở nên quá lớn để thực hiện các yêu cầu chính xác lúc ban đầu. Một vài thành phần chỉ biết được rõ ràng lúc chúng ta xây dựng và kiểm nghiệm hệ thống. Sau khi một hệ thống đồ sộ được hoàn thành, việc hợp nhất các đặc điễm có thể dẫn đến việc “thiếu sót“ chúng lúc kiểm nghiệm hoặc các giai đoạn của ứng dụng phải trả giá đắt và tiêu tốn quá nhiều thời gian. Cách tốt nhất để am hiểu thiết kế hệ thống và phân chia chúng trước khi xây dựng hệ thống hoàn chỉnh đó là xây
dựng và kiểm nghiệm một mô hình làm việc của hệ thống được đề xuất. Một hệ thống mô hình được biết rộng rãi như một nguyên mẫu (prototype) và sự tiến hành được gọi là prototyping. Từ khi cách tiếp cận phân tích và thiết kế hướng đối tượng được giới thiệu, nó trở nên phù hợp nhất đối với mô hình nguyên mẫu (prototyping
paradigm) được minh họa trong hình 11.22
Hình 11.22 mô hình nguyên mẫu
Một nguyên mẫu là một phiên bản kết vảy hạ thấp dần (scaled down) của hệ thống
và có thể không có tiêu chuẩn thực thi nghiêm ngặt và các yêu cầu tài nguyên. Các
System Specifications Outline requirements Design prototype model Build Prototype Make detailed design Full System Evaluate prototype performance
nhà phát triển và các khách hàng đồng ý theo các “đặc tả đường nét đại cương”
(outline specifications) của hệ thống và thiết kế nguyên mẫu được đề nghị với các
yêu cầu đường nét đại cương và các tài nguyên có thể có. Nguyên mẫu sẽ được xây dựng và đánh giá. Điều quan tâm chính không phải là nguyên mẫu mà là sự thực thi của chúng dùng để tinh chỉnh các đặc tả yêu cầu.
Các nguyên mẫu cung cấp một cơ hội để thử nghiệm và phân tích các khía cạnh khác nhau của hệ thống như cấu trúc hệ thống, thiết kế bên trong, các yêu cầu phần cứng và các yêu cầu hệ thống cuối cùng. Lợi ích của cách tiếp cận nguyên mẫu là :
1. Chúng ta có thể trình diễn các đặc tả có thể hiểu được, chúng hợp lý và đầy đủ để có thể chấp nhận được.
2. Người dùng có thể hiểu được điều gì đã xảy ra.
3. Những thay đổi về bảo trì được yêu cầu là tối thiểu khi hệ thống đã cài đặt rồi.
4. Các kỹ sư phát triển có thể làm việc từ một tập hợp các đặc tả mà chúng đã được kiểm nghiệm và chấp thuận.
Prototype có thể nghĩa là đã qua kinh nghiệm. Thường hầu hết chúng không được điều chỉnh vào một sản phẩm. Tuy nhiên, đôi khi có thể điều chỉnh một prototype vào sản phẩm cuối nếu sự thận trọng thích đáng được thực hiện trong việc tái thiết kế prototype. Cách tiếp cận tốt nhất đó là hãy vứt bỏ prototype sau khi sử dụng.
X/ Tóm tắt
Chúng ta đã thảo luận các khía cạnh khác nhau của phân tích và thiết kế hướng đối tượng. Hãy nhớ rằng, đó không phải là cách tiếp cận luôn luôn đem lại tính đúng đắn. Bạn phải xem xét các ý tưởng được đề xuất ở chương này xem nó chỉ là các nguyên tắc chỉ đạo và hãy dùng những kinh nghiệm, sự đổi mới, và sự sáng tạo của bạn trong mọi lúc có thể.
Sau đây là một vài điểm bạn nên suy nghĩ và tiếp tục đổi mới : 1. Thiết lập các mục đích rõ ràng và thực tế
2. Cố gắng dùng các hệ thống đã tồn tại như là các ví dụ hoặc mô hình mẫu để phân tích hệ thống của bạn.
3. Sử dụng các lớp để biểu diễn các khái niệm.
4. Hãy luôn nhớ rằng hệ thống mà bạn tạo ra phải có tính linh động, khả chuyển và có thể mở rộng.
5. Hãy tạo các sưu liệu rõ ràng cho bất cứ điều gì cho hệ thống của bạn. 6. Cố gắng sử dụng lại các hàm và lớp đã có sẵn.
7. Bảo vệ vững chắc các hàm đã định kiểu bất cứ lúc nào có thể được. 8. Sử dụng các prototype bất cứ lúc nào có thể được.
9. Hãy làm cho phù hợp giữa thiết kế và kiểu lập trình
10. Hãy giữ cho hệ thống sáng sủa, đơn giản, gọn nhỏ và có hiệu quả
Bài tập chương 11
1. Hãy liệt kê 5 đặc tính quan trọng nhất, theo ý kiến của bạn, mà các nhà phát triển phần mềm cần lưu tâm khi phát triển một hệ thống ?
2. Hãy mô tả tại sao việc kiểm nghiệm một phần mềm là quan trọng ?
3. Theo bạn bảo trì phần mềm nghĩa là ? Việc thực hiện như thế nào và lúc nào ?
4. Ai là “người chơi” chính trong mỗi giai đoạn của chu kỳ sống phát triển hệ thống ?
5. Có cần thiết nghiên cứu các hệ thống đã tồn tại trong các giai đoạn phân tích ? Nếu có, tại sao ? Nếu không, tại sao ?
6. Những giới hạn của chu kỳ sống phát triển hệ thống cổ điển là gì ?
7. Hãy thảo luận, “Tiến trình phát triển hệ thống là tiến trình lặp đi lặp lại” . 8. Hãy phân biệt giữa mô hình thác nước và mô hình vòi phun nước ?
9. Hãy phân biệt giữa phân tích các hệ thống hướng đối tượng và thiết kế hệ thống hướng đối tượng ? Cái nào yêu cầu tài năng sáng tạo hơn của nhà phát triển hệ thống ?
10. Hãy phân biệt giữa những điều sau :
(a) quan hệ phân loại (classification) và quan hệ hợp thành (composition)
(b) quan hệ kế thừa và quan hệ client-server
(c) Các đối tượng trong không gian vấn đề và trong không gian lời giải (d) Các lược đồ dòng dữ liệu và biểu đồ phân cấp thứ bậc
11. Thảo luận ứng dụng về các kỹ thuật thiết kế có cấu trúc trong lập trình hướng đối tượng.
12. Các vấn đề tiêu chuẩn nào được xem xét trong khi thiết kế các chương trình điều khiển ? Tại sao ?
13. Giải thích lời nhận xét “không một chương trình nào có thể chạy tốt trong lần đầu tiên”
14. Prototyping là gì ? Nó giúp cho việc cải tiến thiết kế hệ thống như thế nào ? 15. Các phát biểu sau đây là đúng hay sai :
(a) Một sự xem xét quan trọng trong khi thiết kế một hệ thống mới chính là người dùng cuối.
(b) Người dùng không đóng vai trò nào trong phân tích và thiết kế hệ thống (c) Một bảng quyết định là một biểu diễn bằng hình ảnh dòng dữ liệu (d) MuÏc đích sử dụng duy nhất của lược đồ dòng dữ liệu là các tư liệu
(e) Lược đồ dòng dữ liệu nhấn mạnh dòng logic của dữ liệu chống lại dòng vật lý của dữ liệu
(f) Các đầu ra (outputs) của máy tính có thể được thiết kế theo ảnh hưởng mang
tính con người
(g) Các kỹ thuật lập trình có cấu trúc không có một vị trí nào trong thiết kế chương trình hướng đối tượng.