Preliminary syntactical remark: UML shows inheritance with an arrow head that is a hollow triangle. The small plain black arrow heads are confusing and might be misunderstood.
What inheritance means: Your diagram means that a bidder and a seller are both guests. Is this what you mean to model? In other words:
Are Bidder and Seller expected to be involved in all their associated use-cases, and on top, all the use-cases of Guest? If yes, it's fine!
But do you really want that an existing Bidder could register as Bidder, or could register as Seller?
If not, consider separation of concerns: distinguish a Guest actor, who could only register, and a Registered user who could login (but is login really a use-case?) and do all the common thing that all registered user can do. Bidder and Seller could then inherit from Registered user.
Other improvements:
associate Make payment and Receive notification to Registered user, because you're not allowed to have several use-cases with the same name. I understand that if the seller makes payment, it's probably the fee for the platform.
have a Pay the auctioned item and associate it to both the seller and the bidder, because one pays, and the other receives the payment : it's in fact two sides of the same use-case.
simplify: use-cases should not be features to add to your software, nor functions to be decompsed. It should be independent user-goals (e.g. Browse items, filter items and view item details are probably three features of one more general use-case View items)
Preliminary syntactical remark: UML shows inheritance with an arrow head that is a hollow triangle. The small plain black arrow heads are confusing and might be misunderstood.
What inheritance means: Your diagram means that a bidder and a seller are both guests. Is this what you mean to model? In other words:
BidderandSellerexpected to be involved in all their associated use-cases, and on top, all the use-cases ofGuest? If yes, it's fine!Biddercould register asBidder, or could register asSeller?Guestactor, who could only register, and aRegistered userwho could login (but is login really a use-case?) and do all the common thing that all registered user can do.BidderandSellercould then inherit fromRegistered user.Other improvements:
associate
Make paymentandReceive notificationtoRegistered user, because you're not allowed to have several use-cases with the same name. I understand that if the seller makes payment, it's probably the fee for the platform.have a
Pay the auctioned itemand associate it to both the seller and the bidder, because one pays, and the other receives the payment : it's in fact two sides of the same use-case.simplify: use-cases should not be features to add to your software, nor functions to be decompsed. It should be independent user-goals (e.g.
Browse items,filter itemsandview item detailsare probably three features of one more general use-caseView items)