<include> and <uses> in UML
I am confused in between <include> and <uses> stereo types in drawing Usecase diagram using UML.
some white papers and books defines <include> and some defines <uses>.
According to me , both are the same indicating that one usecase is using another usecase or one usecase is including another usecase.
Wednesday, May 19, 2004
No Comments.......... Surpized.........
Wednesday, May 19, 2004
Don't worry. This is the "I should't talk with with the unpopular boy, because the popular boys might stop talking to me" syndrome. I have noticed it happens sometimes here in the forum.
3.3 Apply <<include>> When You Know Exactly When To Invoke The Use Case
In Figure 3 you see that the Enroll Student use case includes the use case Enroll in Seminar, it is modeled like this because at a specific point in Enroll Student the logic encapsulated by the included use case is required. In this example part of the task of enrolling a student in the university is to also initially enroll them in one or more seminars, something that is done at step 9 in the use case.
The best way to think of an include association is that it is the invocation of a use case by another one, just like calling a function or invoking an operation within source code. It is quite common to introduce a use case that encapsulates common logic required by several use cases and have that use case included by the ones that require it. It is also common for one use case to include another when the logic of the included use case is invoked in a synchronous manner.
3.5 Introduce <<extend>> associations sparingly
Many use case modelers avoid the use of extend associations as this technique has a tendency to make use case diagrams difficult to understand. My preference is to use extend associations sparingly.
3.7 Do Not Apply <<uses>>, <<includes>>, or <<extends>>
All three of these stereotypes were supported by earlier versions of the UML but over time have been replaced – <<uses>> and <<includes>> were both replaced by <<include>> and <<extends>> was reworked into <<extend>> and generalization. You will likely find these stereotypes applied on old use case diagrams and experienced use case modelers may not yet have transitioned to the newer stereotypes for use case associations.
Anonymous to protect my popularity
Thursday, May 20, 2004
Fog Creek Home