Communication association. In a use case diagram the line linking an actor to a use case is called a communication association (see
50
A STUDENT GUIDE TO OBJECT-ORIENTED DEVELOPMENTFigure 3.2). C o m m u n i c a t i o n associations tell us w h i c h actors are associated w i t h w h i c h use cases. Each actor m a y be associated w i t h m a n y use cases a n d each use case m a y be associated w i t h m a n y actors.
Include. Two o t h e r t y p e s of r e l a t i o n s h i p m a y be u s e d on a use case d i a g r a m - <<include>> a n d <<extend>>. Both <dnclude>> a n d <<extend>>
are relationships b e t w e e n use cases. A n <dnclude>> r e l a t i o n s h i p is useful w h e n y o u find y o u have a c h u n k of b e h a v i o u r t h a t is c o m m o n to several use cases. R a t h e r t h a n repeat a d e s c r i p t i o n of t h a t b e h a v i o u r in several use case descriptions, the c o m m o n b e h a v i o u r can be split off into a separate use case w h i c h is t h e n l i n k e d to all r e l e v a n t use cases w i t h an <dnclude>> relationship. This is a similar idea to the p r o g r a m m i n g t e c h n i q u e of using p r o c e d u r e s or s u b r o u t i n e s to code cohesive bits of f u n c t i o n a l i t y t h a t m a y be u s e d in more t h a n one place in a program. It is i m p o r t a n t to i d e n t i f y f u n c t i o n a l i t y c o m m o n to several use cases because it p e r m i t s the developers to avoid w a s t i n g effort; a c h u n k of f u n c t i o n a l i t y can be identified, i n v e s t i g a t e d a n d m o d e l l e d once, t h e n r e u s e d as r e q u i r e d .
Figure 3-9 shows a refined version of the original W h e e l s use case diagram (see Figure 3.2). The use cases ' M a i n t a i n bike list', ' H a n d l e e n q u i r i e s ' , 'Issue bike' a n d ' H a n d l e bike r e t u r n ' all n e e d to find a p a r t i c u l a r bike from the list of bikes. We therefore create a n e w use case 'Find bike' a n d l i n k it w i t h an <dnclude>> r e l a t i o n s h i p to the four use cases t h a t n e e d it. This tells us t h a t each of these use cases will always use the 'Find bike' use case.
Figure 3.9
Administrator
Receptionist~~
Wheels system
.... <<include>>
- -<ii[ilJJi,
. , . . s "i i I I I:(~'7'~--~
i ss i
| 9 e
.mclude>~
i o ~
"<<include>>
",..._.__....i< <<include>> ,'
Wheels system with includes and extends relationships
USE CASES
LJsE CASE RELATIONSHIPS: COMMUNICATION ASSOCIATIONI INCLUDE AND EXTEND
In the same way, the first part of the use case description for 'Issue bike' repeats the behaviour of the use case 'Handle enquiries', Annie always tells customers the daily hire rate and deposit for a bike before going ahead w i t h the issuing. Rather t h a n repeat a description of this behaviour in both use cases, we can remove it from 'Issue bike' and have an <<include>> relationship b e t w e e n 'Issue bike' and 'Handle enquiries'. Notice that the dashed arrow points from the main use case to the one to be included, e.g. from 'Issue bike' to 'Handle enquiries'.
Extend. The <<extend>> relationship is used as a way of specifying significant alternative behaviour in a use case. It usually d o c u m e n t s functionality that the user can opt to use over and above the norm. The practice of using an <<extend>> relationship in this way is only for d o c u m e n t i n g i m p o r t a n t variations from the normal course of events. Minor variations can be covered in the e x t e n d e d use case description. We w o u l d use an <<extend>>
relationship if we w a n t to describe:
9 Extra functionality that is available if required, for example p r i n t i n g a list r a t h e r t h a n just viewing it on the screen.
9 Behaviour done only u n d e r certain conditions, for example p r i n t i n g an extra receipt if the whole deposit is not r e t u r n e d . If, therefore, we w a n t to specify a c h u n k of behaviour that is additional or exceptional to the normal sequence of events in a use case, we can create a new use case for that behaviour and specify an
<<extend>> relationship b e t w e e n the new and the original use case.
In Figure 3.9 we have created a new use case 'Print receipt' and an
<<extend>> relationship b e t w e e n this use case and 'Handle bike r e t u r n ' . W h a t this means is that sometimes r e t u r n i n g a bike might involve p r i n t i n g a receipt, a l t h o u g h this is not w h a t normally happens. Printing a receipt will only be necessary if the customer has kept the bike for more days t h a n t h e y originally paid for, or if the bike is r e t u r n e d damaged. By contrast, p r i n t i n g a receipt is always part of the 'Issue bike' use case, so we have specified an
<<include>> relationship b e t w e e n 'Issue bike' and 'Print receipt'.
Notice that now the dashed arrow points from the new e x t e n d i n g use case to the main use case, i.e. from ' P r i n t receipt' to 'Handle bike return'. There seems to be no particular reason for this change of direction, it~ just the rule.
If we decide that part of the use case 'Issue bike' will quite often involve adding a new customer, or u p d a t i n g our existing customer details, t h e n it will be sensible to specify an <<extend>> relationship b e t w e e n 'Issue bike' and 'Maintain customer list' (see Figure 3.z o).
An <<extend>> relationship is more a p p r o p r i a t e here t h a n an 51
52 A STUDENT GUIDE TO OBJECT-ORIENTED DEVELOPMENT
Figure 3. I o
Receptionist
.ss ,''~~'--'-~j
<~extend>>', I . ..-'~dnclude>~
| s "
. . . . .include>~
Extract from the Wheels use case diagram showing the r162 relationship between "Issue bike" and "Maintain customer list"
<dnclude>> because we will not always add a new customer, or edit customer details as part of issuing a bike.
Notice that the minor use case is always modelled as an extension of the major one, i.e. the core functionality is specified in the base use case and the additional or exceptional behaviour in the e x t e n d i n g use case.
The user sometimes has to select one of several options at a particular point in the use case; in such cases it may be useful to model each option as a separate e x t e n d i n g use case. The 'alternative courses' section of the e x t e n d e d use case description (see Figure 3.7) is also used for specifying differences in use case behaviour. W h i c h m e t h o d you choose is a matter of j u d g e m e n t .
We have d r a w n a separate diagram (Figure 3.1o) to illustrate the refined version of 'Issue bike' as our main diagram is getting a bit cluttered. This effectively makes the point that <dnclude>> and
<<extend>> should be used sparingly. It is easy to get carried away w i t h enthusiasm w h e n identifying legitimate uses for these relationships, but the resulting model is not always an improvement.
Documenting <<include>> and <<extend>> in the use case description. If we have added <<include>> or <<extend>> relationships to a use case diagram, we must d o c u m e n t t h e m in the use case description. This is done using the k e y w o r d 'initiate'. For example, if the use case 'Issue bike' were to be modelled as specified in Figures 3.9 and 3.1o, we would adjust its use case description to d o c u m e n t the
<dnclude>> and <<extend>> relationships, as in Figure 3.11.