I have a not completed diagram of e-commerce order
I am not sure of the include and extend relatationship
Does this diagram is correct for the attached flow
I have a not completed diagram of e-commerce order
I am not sure of the include and extend relatationship
Does this diagram is correct for the attached flow
About the relationships
An
«extend»
relationshipE - - -> B
means that E extends the behavior of B. B has a meaning on its own independently of its extensions, whereas E adds behavior in the context of B. E may be relevant on its own but it doesn't have to. According to your diagram:Register
extendsLogin
. This would mean thatLogin
is an independent use-case that provides value even without any extension. ConverselyRegister
happens in the context of aLogin
and it could make sense on its own. I'd understand that theLogin
allows also toRegister
new users.An
«include»
relationshipB - - -> I
means that B behavior always includes I behavior. B needs I, but I can is independent of B. According to your diagram:Authentication
includesLogin
. SoAuthentication
requiresLogin
Create order
includesAuthentication
. In consequence, every time an order is created, anauthentication
is performed, which requires aLogin
. Of course, this could make sense in a highly secured ordering system. But for normal business system, this would mean a lot of mandatory logins.Search product
includesView product
. I'd understand that when a user performs a product search, the search results can be viewed, and one could navigate directly to the product view. But it's not clear which actor interacts with the search.About use-cases
Use-cases should have value for the user and correspond to some user goals: Placing an order is certainly a goal for some users. But is the login really a user goal? Isn't it rather some detailed steps required to fulfil other goals? While UML is agnostic about the interaction that a use-case may represent (example argument in favor of a login use-case), use-case gurus usually consider this as a bad practice (example argument against login use-cases).
Use-cases should not be misused for functional decomposition. I'd therefore advise a careful review of the search and view use-cases: are these independent? Do they both provide value to the users? Or is one just a functional detail of the other?