2013-02-28 25 views
16

Sơ đồ trường hợp sử dụng UML cho phép hai cách tương đương dường như cho thấy trường hợp sử dụng nhất định có thể được thực hiện theo một số cách khác nhau là use case generalizations thay vì use case extensions. Tôi đã thấy ví dụ cơ bản sau đây được mô hình hóa bằng cách sử dụng một trong hai cách tiếp cận với tần số bằng nhau, đôi khi trong một nguồn duy nhất.Sử dụng trường hợp tổng quát so với phần mở rộng

Use case generalisation image

Use case extension image

Để tâm trí của tôi một phần mở rộng là một mối quan hệ yếu hơn so với khái quát như một thay thế trực tiếp của các trường hợp sử dụng chuyên ngành đối với trường hợp cơ sở phải có thể trong sự tổng quát nhưng không nhất thiết ở phần mở rộng.

Dường như với tôi rằng khái quát hóa ngụ ý việc thực hiện đa hình là mong muốn trong khi phần mở rộng ngụ ý một số cấu trúc phân nhánh sẽ được sử dụng.

void makePayment(const PaymentDetails* pd) 
{ 
    pd->pay(); 
} 

như trái ngược với

void makePayment(const PaymentDetails* pd) 
{ 
    switch(pd->type) 
    { 
     case EFT: 
       payViaEFT(pd); 
       break; 
     case PAYPAL: 
       payViaPayPal(pd); 
       break; 
     case CREDITCARD: 
       payViaCreditCard(pd); 
       break; 
    } 
} 

Không phải là giai đoạn sử dụng Case quá sớm để lo ngại thực hiện như vậy cụ thể để được mô hình? Có nhiều sơ đồ UML thích hợp hơn cho điều đó. Có một quy tắc cứng nhắc và nhanh chóng nào liên quan đến việc sử dụng cái nào và nếu nó là gì?

+1

Cả hai triển khai đều mô hình cùng một vấn đề. Chúng không liên kết với một sơ đồ UC hay sơ đồ khác. Một hình đa hình thì hấp dẫn hơn nhiều, vì nó đơn giản hơn, dễ mở rộng hơn và ít bị lỗi của con người hơn. –

Trả lời

11

Để tâm trí của tôi một phần mở rộng là một mối quan hệ yếu hơn so với khái quát như một thay thế trực tiếp của các trường hợp sử dụng chuyên ngành đối với trường hợp cơ sở phải có thể trong sự tổng quát nhưng không nhất thiết ở phần mở rộng.

Điều đó đúng.

Dường như với tôi khái quát rằng ngụ ý một đa hình thực hiện được mong muốn trong khi mở rộng bao hàm một số nhánh cấu trúc được sử dụng.

Sơ đồ không quy định bất kỳ triển khai nào. Tuy nhiên, bạn có thể giải thích gợi ý từ sơ đồ cho chính mình. UML vẫn độc lập với ngôn ngữ và giải pháp ở đó.

Giai đoạn không phải là trường hợp sử dụng quá sớm để thực hiện như vậy các mối quan tâm cụ thể được mô hình hóa?

Vâng, như đã nêu ở trên, UML không thực thi bất kỳ loại triển khai cụ thể nào. Tuy nhiên, bạn đang thu thập một số yêu cầu chức năng quan trọng ở đây có thể ảnh hưởng lớn đến lịch trình thời gian và khối lượng công việc của bạn. ("Thanh toán bằng thẻ tín dụng" là cách phức tạp hơn để xử lý hơn "thanh toán trước bằng chuyển khoản ngân hàng"). Vì vậy, bạn sẽ cố gắng nắm bắt điều đó nhưng vẫn mở cho các phương pháp tiếp cận giải pháp khác nhau.

Có nhiều sơ đồ UML phù hợp hơn cho điều đó.

Bạn thực sự có thể sử dụng chúng song song :) vì chúng là các chế độ xem khác nhau về cùng một chủ đề.

Có quy tắc nhanh chóng và nhanh chóng về việc sử dụng cả hai để sử dụng và nếu có thì nó là gì?

Tôi thích sự khái quát hóa trong trường hợp này bởi vì thực tế các tiện ích mở rộng cho rằng có thể là cách thanh toán mà không sử dụng bất kỳ tùy chọn nào trong ba tùy chọn được đặt tên. Như bạn đã chỉ ra.

7

Khi lập mô hình có mối quan hệ mở rộng, trường hợp sử dụng mở rộng (thanh toán qua xxx) được thực hiện khi trường hợp sử dụng mở rộng (thanh toán) ở vị trí chính xác (được cung cấp bởi điểm mở rộng, loại thanh toán) nếu điều kiện mối quan hệ mở rộng như vậy giữ (ví dụ như "Thanh toán qua Paypal", điều kiện sẽ là payment_type = PAYPAL). Trong mô hình này, "Thanh toán qua Paypal" chỉ đề cập đến chi tiết hoàn thành giao dịch thanh toán với Paypal, trong khi "Thanh toán" chỉ định tất cả các hành vi độc lập với phương thức thanh toán (chẳng hạn như tính tổng số tiền và lưu kết quả của giao dịch khi nó đã được thực hiện). Mặt khác, khái quát hóa (được định nghĩa không chỉ cho các trường hợp sử dụng, mà còn cho bất kỳ trình phân loại nào) là một khái niệm rộng hơn, vì nó không chi tiết (ở cấp sơ đồ) chi tiết về thời gian và cách thức chuyên môn hóa hành vi được thực hiện. Nếu "Thanh toán qua Paypal" là một chuyên môn về "Thanh toán", nó sẽ xác định lại hành vi của "Thanh toán", điều này có thể khác biệt đáng kể so với hành vi "Thanh toán qua thẻ tín dụng".

Là trường hợp sử dụng mở rộng không có nghĩa là các lựa chọn thay thế phải được mã hóa cứng. Thật vậy, ví dụ đầu tiên của bạn cũng là việc triển khai hợp lệ mối quan hệ mở rộng, vì pd->pay(pd) sẽ gọi các hành vi khác nhau tùy thuộc vào loại thanh toán đã chọn. Trên thực tế, sử dụng mô hình sơ đồ trường hợp hệ thống được yêu cầu làm, trong khi chi tiết triển khai cấp thấp được chỉ định rõ hơn trong biểu đồ hoạt động.

3

Ví dụ về tiện ích sẽ là trường hợp sử dụng "Nhập mã giảm giá". Việc nhập mã giảm giá phải thực hiện với việc thanh toán, nhưng bạn không phải nhập mã để thực hiện thanh toán.

Bạn có thể xem mối quan hệ "là" để xác định sử dụng. Thanh toán bằng PayPal "là" thanh toán, một cách cụ thể để thanh toán. Nhập mã giảm giá là không. Đó là một cái gì đó bổ sung bạn có thể làm trong khi thực hiện thanh toán.

+0

Tôi thấy những gì bạn đang nói. Thực hiện Thanh toán không hoàn chỉnh bởi chính nó nên mối quan hệ tự nhiên nhất để sử dụng sẽ là khái quát hóa (đó là điều tôi ưu tiên). Tuy nhiên, việc sử dụng khái quát hóa dường như ngụ ý rằng không thể sử dụng nhiều hình thức thanh toán cùng một lúc. [Một số người] (http://www.uml-diagrams.org/use-case-include.html) nói rằng việc thêm khả năng đặt điều kiện vào các mối quan hệ bao gồm sẽ hữu ích để tránh những vấn đề này. Suy nghĩ của bạn? – DuncanACoulter

+0

Tôi đã xem sự cố được tác giả nêu trong liên kết của bạn. Có một giải pháp dễ dàng. Nếu bạn nghĩ về nó, "một" thanh toán với hai phương pháp thực sự là hai khoản thanh toán. Tác giả đang bị treo lên trên ý tưởng rằng nhiều phương thức thanh toán phải là một lần đi qua trường hợp sử dụng thanh toán. Bạn có thể thực hiện một lần cho mỗi phương thức thanh toán. Nếu bạn muốn liên kết nhiều giao dịch thanh toán thành một khoản thanh toán hợp lý, sau đó mở rộng trường hợp Sử dụng thanh toán, thêm trường hợp sử dụng "Xử lý nhiều phương thức thanh toán" hoặc một số trường hợp như vậy, liên kết nhiều lần qua Thanh toán. – BobRodes

+2

Ngoài ra, trong khi tôi thấy điểm bây giờ về việc có thể sử dụng mở rộng để xử lý nhiều khoản thanh toán, tôi vẫn nghĩ rằng việc sử dụng mô hình khái quát là chính xác hơn. Việc sử dụng mở rộng không phân biệt giữa các phương thức thanh toán đơn lẻ và nhiều phương thức thanh toán rõ ràng. – BobRodes

Các vấn đề liên quan