Name the use cases see Section 668 3 Describe the use cases briefly by applying

Name the use cases see section 668 3 describe the use

This preview shows page 116 - 118 out of 243 pages.

2. Name the use cases (see Section 6.6.8). 3. Describe the use cases briefly by applying terms with which the user is familiar. This makes the description less ambiguous. Once you have identified the use-cases candidates, it may not be apparent that all of these use cases need to be described separately; some may be modeled as variants of others. Consider what the actors want to do. It is important to separate actors from users. The actors each represent a role that one or several users can play. Therefore, it is not necessary to model different actors that can perform the same use case in the same way. The approach should allow different users to be different actors and play one role when performing a particular actor's use case. Thus, each use case has only one main actor. To achieve this, you have to . Isolate users from actors. . Isolate actors from other actors (separate the responsibilities of each actor). .Isolate use cases that have different initiating actors and slightly different behavior (if the actor had been the same, this would be modeled by a use-case alternative behavior) . While finding use cases, you might have to make changes to your set of actors. All actor changes should be updated in the textual description of actors and use cases. The change should be carried out with care, since changes to the set of actors affect the use cases as well.
Image of page 116
117 When specifying use cases, you might discover that some of them are variants of each other. If so, try to see how you can reuse the use case through extends or uses associations . How Detailed Must a Use Case Be? When to Stop Decomposing and When to Continue A use case, as already explained, describes the courses of events that will be carried out by the system. Jacobson et al. believe that, in most cases, too much detail may not be very useful. During analysis of a business system, you can develop one use-case diagram as the system use case and draw packages on this use case to represent the various business domains of the system. For each package, you may create a child usecase diagram (see the case in Section 6.7 for an example). On each child use-case diagram, you can draw all of the use cases of the domain, with actions and interactions. You can further refine the way the use cases are categorized. The extends and uses relationships can be used to eliminate redundant modeling of scenarios. When should use cases be employed? Use cases are an essential tool in capturing requirements and planning and controlling any software development project. Capturing use cases is a primary task of the analysis phase. Although most use cases are captured at the beginning of the project, you will uncover more as you proceed. How many use cases do you need? Ivar Jacobson believes that, for a lO- personyear project, he would expect 20 use cases (not counting the uses and extends associations). Other researchers, such as Fowler and Scott, would come up with 100 use cases for a project of the same magnitude. Some prefer smaller grained, more detailed use cases. There is no magic formula; you need to be flexible and work with whatever
Image of page 117
Image of page 118

You've reached the end of your free preview.

Want to read all 243 pages?

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

Stuck? We have tutors online 24/7 who can help you get unstuck.
A+ icon
Ask Expert Tutors You can ask You can ask You can ask (will expire )
Answers in as fast as 15 minutes