Tôi muốn biết các bước cần làm theo để tiếp cận các vấn đề như thiết kế máy bán hàng tự động và đưa ra một số tài liệu thiết kế (như trường hợp sử dụng, trình tự sơ đồ, sơ đồ lớp). Có bất kỳ nguồn/liên kết nào mà tôi có thể đọc ở nơi nó nói về cách đi từng bước.Làm thế nào để tiếp cận các vấn đề thiết kế như "thiết kế máy bán hàng tự động"
Cảm ơn.
Tôi không chắc liệu có bất kỳ bộ bước được chấp nhận phổ biến nào hay không, nhưng điều dễ nhất là chỉ cần phá vỡ từng bước theo như bạn có thể thực hiện.
Sau đó, bạn có thể căn cứ sơ đồ trình tự và sơ đồ lớp của bạn khỏi những gì bạn đã nghĩ ra.
Tôi thích cách tiếp cận "fractalization" này! +1 – Janie
Vâng, máy bán hàng tự động về cơ bản là state machine.
Tôi sẽ quyết định đầu vào hợp lệ sẽ là gì (tiền xu và hóa đơn?) Và kết quả đầu ra sẽ là gì.
Kết quả có khả năng xảy ra khi người dùng đi tới máy. Vấn đề gì có thể xảy ra? (quá nhiều tiền, quá ít tiền) Làm thế nào họ sẽ được xử lý? (thay đổi phân phối, hoàn tiền phân phối)
Cuối cùng, hãy viết ra những thứ bạn cần để xử lý các trường hợp sử dụng. Danh từ của bạn có thể là Lớp học. Động từ của bạn có thể là các phương thức thuộc về các lớp đó.
chung, suy nghĩ về những gì các đối tượng được tham gia vào một máy bán hàng tự động:
VendingMachine - có thể là một lớp trừu tượngDrinkMachine, SnackMachine, và các lớp học mở rộng VendingMachineVendingProduct - một lớp trừu tượng?Drink, các lớp học khác mở rộng VendingProductCoke, các lớp học khác mở rộng DrinkNhưng tôi chắc chắn bạn có thể hiểu điều đó khá dễ dàng. Các hạt và bu lông của máy sẽ diễn ra trong một số loại lớp tiện ích, với các phương thức chấp nhận hóa đơn và tiền xu, tính toán thay đổi, v.v.
Tiếp tục đọc:
Liên kết đầu tiên đã chết, bạn có thể cung cấp liên kết khác cho điều đó không? – ahujamoh
Đã cập nhật với phiên bản đã lưu trữ: https://web.archive.org/web/20090228114745/http://www.ibm.com/developerworks/webservices/library/ws-oo-design1/ –
liên kết đầu tiên cũng đã chết. đây là địa chỉ mới: http://www.maheshsubramaniya.com/article/object-oriented-programming-encapsulation-is-not-just-hiding-data.html – Yar
bắt đầu bằng cách định nghĩa "máy nhà cung cấp":
Một máy nhà cung cấp là một máy tính mà .....
mau! có yêu cầu của bạn.
Những suy nghĩ có thể giúp:
Từ một quan điểm giao diện xác định đầu vào, đầu ra, điều kiện dự kiến, điều kiện lỗi.
Quyết định mức độ cần xem xét.
Mất bao lâu để hoạt động (tuổi thọ).
Tần suất cần thiết phải hoàn nguyên?
Tôi giả sử bạn đã thấy this link rồi.
Đừng suy nghĩ về mã (lớp học, & c.) Trước tiên. Hãy suy nghĩ về các trường hợp sử dụng và các yêu cầu chức năng. Chức năng của máy bán hàng tự động được cung cấp là gì? Người dùng được mong đợi tương tác với nó như thế nào? Làm thế nào về các nhà bảo trì? Cố gắng không nhầm lẫn các chi tiết triển khai từ các nhu cầu cấp cao trong khi thực hiện việc này.
Sau đó, tùy thuộc vào loại dự án
lớp
này dành cho, hãy suy nghĩ về các yêu cầu không phải chức năng. Thuộc tính quan trọng nhất: tốc độ, độ tin cậy, dễ bảo trì, khả năng thích ứng với tình huống mới, bảo mật, ...? Có những khả năng khác. Đây không phải là nhị phân, có/không có câu trả lời, suy nghĩ nhiều hơn về phạm vi và tiêu chuẩn tối thiểu so với mục tiêu tối ưu. Lưu ý, "tối ưu" phụ thuộc vào quan điểm của bên liên quan được đề cập. Dễ sử dụng và bảo mật thường xung đột, vì vậy bạn phải tìm ra cái nào là quan trọng hơn.
Sau đó, bạn có thể quay lại các trường hợp sử dụng và xem chúng bị ảnh hưởng như thế nào bởi các yêu cầu không hoạt động của bạn. Đây là nơi thương lượng xảy ra với khách hàng của bạn, những người trong trường hợp này có lẽ là bạn. Bạn có phải hy sinh các tính năng để đáp ứng một số mục tiêu khác không? Đối với mỗi tính năng, rủi ro so với phần thưởng là gì? Dễ dàng thực hiện các tính năng cung cấp giá trị cao là rất tốt. Khó thực hiện (do các ràng buộc) các tính năng chỉ thêm giá trị nhỏ nên được ưu tiên rõ ràng nhất. Hai kết hợp khác yêu cầu suy nghĩ cẩn thận.
Sau đó, bạn có thể bắt đầu thiết kế máy.
Có rất nhiều sơ đồ khác nhau mà bạn có thể sử dụng để giúp bạn trực quan hóa vấn đề hoặc giải thích giải pháp được đề xuất của bạn cho người khác.
Không chỉ có một cách phù hợp để thiết kế tất cả phần mềm từ đầu!
Có thể có hàng tá phương pháp tiếp cận khác nhau, từ thiết kế trả trước rất nhỏ như trong Evolutionary Design đến Thiết kế mặt trận lớn được viết lên trong August 2005 on JoelOnSoftware. Có lẽ nhiều hơn một vài phương pháp inbetween có vị trí của chúng, vì vậy nó phụ thuộc vào phương pháp phát triển bạn muốn sử dụng vì một số có thể yêu cầu thiết kế trả trước hơn như trong phương pháp Waterfall so với Agile có yêu cầu thay đổi thường xuyên và điều này không t gây ra rất nhiều vấn đề hoặc ít nhất đó là lý thuyết.
Để tiếp cận vấn đề như vậy
Xác định yêu cầu, chức năng usecase
lao xuống các yêu cầu này vào nhiệm vụ tầm thường và cơ bản
và chắc chắn hỏi rất nhiều câu hỏi để xóa các yêu cầu
Đối với một số vấn đề (như máy bán hàng tự động), nó có thể được giải quyết bằng thiết kế hướng đối tượng với Máy trạng thái.
Trạng thái ban đầu không hoạt động và chuyển sang nhập nếu bắt đầu nhập, cho phép xóa, hủy và gửi khi nhập hàng và số cột, sau đó sẽ xử lý thanh toán sau khi gửi hàng và số cột, cuối cùng sẽ pop ra mục nếu thanh toán thành công, nếu không trả tiền một lần nữa. Đối với các lớp học trong máy bán hàng tự động, cần có một số nút để chỉ ra hàng (A, B, C) và cột (1, 2, 3) số, một số nút để xóa, hủy hoặc gửi số hàng và cột, một số khe cắm để chấp nhận thanh toán (tiền mặt, tiền xu, thẻ tín dụng/thẻ ghi nợ), một số khe cắm để giữ các vật phẩm (đồ uống, đồ ăn nhẹ, vv).
Tham khảo blog
Jesse Liberty đã viết một cuốn sách tốt về điều này: http://www.amazon.com/Beginning-Object-Oriented-Analysis-Design-C/dp/1861001339 – Robert
Nó có vẻ là bài tập về nhà. – Tiger
Nó có lẽ là bài tập về nhà, nhưng hes không yêu cầu các trường hợp sử dụng được rút ra cho anh ta. Anh ta chỉ cần một cú đẩy đúng hướng. – Brandon