tags:

views:

74

answers:

5

Or the "extends" is a use case inheriting another?

--update

Just a clarification, I've read books and made a lot of diagrams. But I just can't see any difference between extends on UML and on inherance. As Bill said, UML extends indicates optional behavior, but in inherance either you get new behavior you can or not use. So, what's the difference?

A: 

No this is not inheritance. Rather it is typically used to indicate optional behavior. See this article.

Bill W
the extended case is a behaviour that can be used or not. Like when I extend a class, I can use it's behaviours or not...
Tom Brito
@Bill - I disagree - as the link you provided states "one use case (extension) extends the behavior of another use case" This is the basis of inheritance.
Doug
+1  A: 

Hi,

This is very similar to inheritance. See a detailed description of this concept here.

Enjoy!

Doug
+2  A: 

I think in UML the difference is in that "extends" is based on extension points, which means there has to be a named point in the use case where the extension will be applied. The semantics are not very precise about this. Inheritance for use cases means changing some behaviour, not exzactly specifying where.

Another important point is about the inheritance and the Liskov substitution principle. You should be able to use one use case, which inherits from another, in any place you can use the another one. This does not hold for the way "extends" is understood. When one use case is extended by another, it means that one might be modified by another, but still it contains the main scenario path, which might be forked and joined by the extending use case. This is, I think, about the difference between structural and behavioural inheritance. Inheritance is about achieving the same goal and satisfying the same interests - same responsibility and behaviour constraints, where extension is about modification of the structure of the path of scenario, which might be triggered by additional interests - like error checking.

Inheritance actually is not a very good mechanism to be used for use cases, combined with actor inheritance, which makes more sense, it can lead to unwanted paradoxes. Following the advice of Alistair Cockburn (Writing effective Use Cases), inheritance should be used only for expressing variations in technical details or data formats for a particular use case.

Gabriel Ščerbák
A: 

sorry but this answer "This is very similar to inheritance" is totally incorrect it have nothing in common and the meaning are (as an example) if you are on a dinner you COULD extends your dineer with a coffe. In that case dinner EXTENDS coffe if you are paying something online that use case HAVE to inherit the use case "validate user" because you always must validate the user before make a money transactions.

so extends=sometimes inherit=always.

kind regards mike from: UML Tools

alud
+1  A: 

In the tool I use in my company we have modeling restrictions.

Inheritance: From Actor to Actor, from UseCase to Usecase, from System to System. You can't have other inheritances in your diagram because I got a forbidden sign.

Extend can only be done between two Usecases and not between other elements.

I don't really see the difference between inheritance and extends between two usecases. I will keep on reading the next posts because after reading all answers I still don't understand:-)