Academia.eduAcademia.edu

Figure 5 – uploaded by shashank nawathe

See full PDFdownloadDownload figure
Figure 3.6. Two use cases with a common behavior

Figure 3 6. Two use cases with a common behavior

Related Figures (72)

Actors versus Roles modeling, allowing models to be simplified and made more expressive. The fact that actors are classes means that actors can be generalized. Through the generalization process, similarities between different actors can be identified. The UML icon for generalization is a small hollow arrowhead pointing at the superclass of the actor. For instance, a generic actor, such as System Designer, can be inherited by other actors, such as System Analyst and Project Manager. Figure 3.2 shows that the inheriting actors (System Analyst and Project Manager) also inherit the Use Cases associated with the inherited Actor (System Designer).
Actors versus Roles modeling, allowing models to be simplified and made more expressive. The fact that actors are classes means that actors can be generalized. Through the generalization process, similarities between different actors can be identified. The UML icon for generalization is a small hollow arrowhead pointing at the superclass of the actor. For instance, a generic actor, such as System Designer, can be inherited by other actors, such as System Analyst and Project Manager. Figure 3.2 shows that the inheriting actors (System Analyst and Project Manager) also inherit the Use Cases associated with the inherited Actor (System Designer).
Figure 3.4. A use case model for an ATM system Example 2: A Hotel Information System In this example, consider a simple hotel information system for two groups of customers: Tour Group customers and Individual customers. Tour Group customers are those who have made advanced reservations through a tour operator, while Individual customers make their reservations directly with the hotel. Both groups of customers can book, cancel, check-in and check-out of a room by phone or via the Internet. TTY ...4y 2... )0h 6g On eg ey ee r,s is They operate the ATM to withdraw and deposit money, check the account
Figure 3.4. A use case model for an ATM system Example 2: A Hotel Information System In this example, consider a simple hotel information system for two groups of customers: Tour Group customers and Individual customers. Tour Group customers are those who have made advanced reservations through a tour operator, while Individual customers make their reservations directly with the hotel. Both groups of customers can book, cancel, check-in and check-out of a room by phone or via the Internet. TTY ...4y 2... )0h 6g On eg ey ee r,s is They operate the ATM to withdraw and deposit money, check the account
Use Case Analysis Techniques
Use Case Analysis Techniques
Base Use Case versus Abstract Use Case Once a set of use cases of the system has been identified, common behaviors may be found. By extracting their common behaviors, we can form a base case concrete use case) and an abstract use case. The former is basically the main use case which may be instantiated directly by an actor as it can achieve an observable user goal by itself. The latter can only be instantiated by a base use case as it only contains a portion of the common behaviors shared among two yr more use cases. Therefore, it is not a complete goal from the user’s perspective. For example, in Figure 3.8, a use case such as Login Account is not a4 use case but an abstract use case (or an <<include>> use case), because logging into the system does not achieve a complete user goal. A goal is not achieved if a user goes to an ATM, logs in to the system and then leaves without making a transaction. Typical operations a user may want to carry out through an ATM could be Check Balance, Request Check Book or Deposit Money, etc. A use case may also exhibit several scenarios: the normal scenario and possible several alternative scenarios. Similarly, the base use case can be used ~~ noenencant tha narmal ereoanarin wihiloa ahetrant weo pacoac Aacevihoa tha A child use case can inherit the behaviors, relationships and communication links of a parent use case. In other words, it is valid to put the child use case wherever a parent use case appears. The relationship between the child use case and the parent use case is the generalization relationship. For example, suppose the ATM system can be used to pay bills. Pay Bill has two child use cases: Pay Credit Card Bill and Pay Utility Bill (see Figure 3.10).
Base Use Case versus Abstract Use Case Once a set of use cases of the system has been identified, common behaviors may be found. By extracting their common behaviors, we can form a base case concrete use case) and an abstract use case. The former is basically the main use case which may be instantiated directly by an actor as it can achieve an observable user goal by itself. The latter can only be instantiated by a base use case as it only contains a portion of the common behaviors shared among two yr more use cases. Therefore, it is not a complete goal from the user’s perspective. For example, in Figure 3.8, a use case such as Login Account is not a4 use case but an abstract use case (or an <<include>> use case), because logging into the system does not achieve a complete user goal. A goal is not achieved if a user goes to an ATM, logs in to the system and then leaves without making a transaction. Typical operations a user may want to carry out through an ATM could be Check Balance, Request Check Book or Deposit Money, etc. A use case may also exhibit several scenarios: the normal scenario and possible several alternative scenarios. Similarly, the base use case can be used ~~ noenencant tha narmal ereoanarin wihiloa ahetrant weo pacoac Aacevihoa tha A child use case can inherit the behaviors, relationships and communication links of a parent use case. In other words, it is valid to put the child use case wherever a parent use case appears. The relationship between the child use case and the parent use case is the generalization relationship. For example, suppose the ATM system can be used to pay bills. Pay Bill has two child use cases: Pay Credit Card Bill and Pay Utility Bill (see Figure 3.10).
Figure 3.12. Use case diagram showing <<include>> and <<extend>> relationships Documenting Use Cases
Figure 3.12. Use case diagram showing <<include>> and <<extend>> relationships Documenting Use Cases
For example, the ATM system may provide the Withdraw Money service to customers in many different scenarios. A typical scenario may involve the customer withdrawing money from the machine from which he/she has requested the transaction. In another scenario, the system may report that the password keyed in by the customer is incorrect, requiring the customer to re-enter the password. Figure 3.13 conceptualizes that a use case can be elaborated by a use case description in a more detailed form in that a use case description is explained and elaborated through scenarios (a sequence of actions). Each of these scenarios is simply an instance of the use case. In other words, a use case instance is only a particular example of a use case (a particular system service). As defined by Booch, a use case not only consists of a normal scenario, but possibly its variant scenarios. In such cases, they need to be represented in <<extend>> use cases, where each should be elaborated by a separate use case description.
For example, the ATM system may provide the Withdraw Money service to customers in many different scenarios. A typical scenario may involve the customer withdrawing money from the machine from which he/she has requested the transaction. In another scenario, the system may report that the password keyed in by the customer is incorrect, requiring the customer to re-enter the password. Figure 3.13 conceptualizes that a use case can be elaborated by a use case description in a more detailed form in that a use case description is explained and elaborated through scenarios (a sequence of actions). Each of these scenarios is simply an instance of the use case. In other words, a use case instance is only a particular example of a use case (a particular system service). As defined by Booch, a use case not only consists of a normal scenario, but possibly its variant scenarios. In such cases, they need to be represented in <<extend>> use cases, where each should be elaborated by a separate use case description.
Table 3.2. Components of a use case template
Table 3.2. Components of a use case template
Step 4: Create Initial Use Case Diagram
Step 4: Create Initial Use Case Diagram
Identify/Refine Candidate Business (Domain) Classes
Identify/Refine Candidate Business (Domain) Classes
Note: Recall that a use case model often consists of several use cases. Each of the use cases has its own corresponding use case description, including its brief description and the flow of events, providing more details. As progress is made in the development of the project, more and more use cases will be developed according to the use case schedule. Iteratively and incrementally refine and enrich the initial class model (Figure 3.17) by performing the textual analysis for each of the use cases that have been developed. Table 3.6. Textual analysis on the Schedule Delivery use case is made in the development of the project, more and more use cases will be
Note: Recall that a use case model often consists of several use cases. Each of the use cases has its own corresponding use case description, including its brief description and the flow of events, providing more details. As progress is made in the development of the project, more and more use cases will be developed according to the use case schedule. Iteratively and incrementally refine and enrich the initial class model (Figure 3.17) by performing the textual analysis for each of the use cases that have been developed. Table 3.6. Textual analysis on the Schedule Delivery use case is made in the development of the project, more and more use cases will be
Chapter 3: Use Case Modeling and Analysis 108 The initial use case model is expanded incrementally in subsequent phases of the system development life cycle. In each phase, some use cases are selected and analyzed to produce detailed specifications of the necessary behavioral and functional requirements. Common behaviors and alternative behaviors of use cases are identified when the use cases are expanded and analyzed. These behaviors are extracted to become inclusion, extension and generalization use cases. These, in turn, help to make the use case model easier to maintain. The classes identified in the analysis of the use cases are used to update and refine the class model.
Chapter 3: Use Case Modeling and Analysis 108 The initial use case model is expanded incrementally in subsequent phases of the system development life cycle. In each phase, some use cases are selected and analyzed to produce detailed specifications of the necessary behavioral and functional requirements. Common behaviors and alternative behaviors of use cases are identified when the use cases are expanded and analyzed. These behaviors are extracted to become inclusion, extension and generalization use cases. These, in turn, help to make the use case model easier to maintain. The classes identified in the analysis of the use cases are used to update and refine the class model.
The revised descriptions of the Place Order and Find Member Record use ases are shown in Tables 3.8 and 3.9 respectively.
The revised descriptions of the Place Order and Find Member Record use ases are shown in Tables 3.8 and 3.9 respectively.
No member record is found for the customer. Table 3.9. Description of the Find Member Record use case
No member record is found for the customer. Table 3.9. Description of the Find Member Record use case
Table 3.10. Instance Scenario of Place Order
Table 3.10. Instance Scenario of Place Order
Tricks and Tips in Using Use Case Analysis Chapter 3: Use Case Modeling and Analysis 108
Tricks and Tips in Using Use Case Analysis Chapter 3: Use Case Modeling and Analysis 108
externally observable behaviors of an ATM system, but no customer would ever set his/her goal as inputting the password, selecting a transaction and then leaving the ATM. Furthermore, both Input Password and Select Transaction use cases do not yield an observable value to the user and, therefore, cannot achieve a user goal.
externally observable behaviors of an ATM system, but no customer would ever set his/her goal as inputting the password, selecting a transaction and then leaving the ATM. Furthermore, both Input Password and Select Transaction use cases do not yield an observable value to the user and, therefore, cannot achieve a user goal.
Apply Textual Analysis in Different Contexts
Apply Textual Analysis in Different Contexts
Structure Use Case Models
Structure Use Case Models
Figure 3.26. Identifying major actors
Figure 3.26. Identifying major actors
Figure 3.30. Creating an Actor in model repository
Figure 3.30. Creating an Actor in model repository
Figure 3.29. Entering actor description in Class Description
Figure 3.29. Entering actor description in Class Description
Figure 3.32. Actor models in Model Repository Tree
Figure 3.32. Actor models in Model Repository Tree
Figure 3.33. Hiding Actors in Candidate Class Container Step 3: Identify Use Cases
Figure 3.33. Hiding Actors in Candidate Class Container Step 3: Identify Use Cases
Figure 3.34. Creating a candidate use case in Candidate Class Container 3.3. An input dialog will appear. Enter Place Order in the input dialog (see Figure 3.35).
Figure 3.34. Creating a candidate use case in Candidate Class Container 3.3. An input dialog will appear. Enter Place Order in the input dialog (see Figure 3.35).
Figure 3.35. Naming a new candidate use case
Figure 3.35. Naming a new candidate use case
Figure 3.37. Creating a brief use case description
Figure 3.37. Creating a brief use case description
Figure 3.38. Adding a candidate use case to Model Repository 3.7. Anew use case is added to the Model Repository Tree (see Figure 3.39). Figure 3.39. A new use case in Model Repository Tree
Figure 3.38. Adding a candidate use case to Model Repository 3.7. Anew use case is added to the Model Repository Tree (see Figure 3.39). Figure 3.39. A new use case in Model Repository Tree
Figure 3.40. Use cases in Model Repository Tree
Figure 3.40. Use cases in Model Repository Tree
© C:\VP-UML Projects\MailOrderSystem.vpp * - Visual Paradigm for
© C:\VP-UML Projects\MailOrderSystem.vpp * - Visual Paradigm for
Figure 3.45. Creating an association relationship using resource-centric icon
Figure 3.45. Creating an association relationship using resource-centric icon
Figure 3.44. Creating an Actor with Model Repository Tree
Figure 3.44. Creating an Actor with Model Repository Tree
Step 5: Describe Use Cases The use cases created require further elaboration so that the next phase of the
Step 5: Describe Use Cases The use cases created require further elaboration so that the next phase of the
Figure 3.47. Use case right click pop-up menu 5.2. Select the Description tab (see Figure 3.48). A Specification Dialog about the files associated to the element will be displayed.
Figure 3.47. Use case right click pop-up menu 5.2. Select the Description tab (see Figure 3.48). A Specification Dialog about the files associated to the element will be displayed.
Figure 3.48. Use case specification setup
Figure 3.48. Use case specification setup
Figure 3.49. Use case specification and template
Figure 3.49. Use case specification and template
Figure 3.50. Launching textual analysis function with a use case
Figure 3.50. Launching textual analysis function with a use case
Figure 3.52. Identifying candidate classes
Figure 3.52. Identifying candidate classes
Figure 3.54. Inputting class description for Order class
Figure 3.54. Inputting class description for Order class
Figure 3.53. All occurrences of candidate class are highlighted
Figure 3.53. All occurrences of candidate class are highlighted
Figure 3.55. Candidate classes in Candidate Class Container
Figure 3.55. Candidate classes in Candidate Class Container
Figure 3.56. Adding new items to Use Case Template Note: The Add Item option appends an item at the end of the Use Case Template, while the Insert Item option creates an element after the current highlighted position of the Use Case Description.
Figure 3.56. Adding new items to Use Case Template Note: The Add Item option appends an item at the end of the Use Case Template, while the Insert Item option creates an element after the current highlighted position of the Use Case Description.
Figure 3.57. Renaming items in Use Case Template
Figure 3.57. Renaming items in Use Case Template
Figure 3.58. The completed use case description
Figure 3.58. The completed use case description
Figure 3.59. Creating a new package
Figure 3.59. Creating a new package
Figure 3.61. Structuring use cases into a package within a package at multiple levels. When a package is moved around the
Figure 3.61. Structuring use cases into a package within a package at multiple levels. When a package is moved around the
Figure 3.62. Structuring the use cases into packages
Figure 3.62. Structuring the use cases into packages
Figure 3.64. Complete use case model structured into packages Having grouped the use cases into packages according to the actors’ roles and responsibilities, further structure the use cases according to their common pattern as well as their interactive flow pattern. If some common behaviors are found in two or more use cases, we can factor them out by creating an <<include>> use case. On the other hand, if some alternative scenarios arise due to some special condition(s), we can handle these by introducing the <<extend>> use case(s). Now, let us structure the use case model for the Find Member Record <<include>> use case. If a system boundary will eventually be placed in the use case model, it is better to create the boundary at the beginning before the first use case is created. This way, use cases are created inside the boundary without having to move the use cases and actors around to place them in the right position (see Figure 3.64).
Figure 3.64. Complete use case model structured into packages Having grouped the use cases into packages according to the actors’ roles and responsibilities, further structure the use cases according to their common pattern as well as their interactive flow pattern. If some common behaviors are found in two or more use cases, we can factor them out by creating an <<include>> use case. On the other hand, if some alternative scenarios arise due to some special condition(s), we can handle these by introducing the <<extend>> use case(s). Now, let us structure the use case model for the Find Member Record <<include>> use case. If a system boundary will eventually be placed in the use case model, it is better to create the boundary at the beginning before the first use case is created. This way, use cases are created inside the boundary without having to move the use cases and actors around to place them in the right position (see Figure 3.64).
Chapter 3: Use Case Modeling and Analysis 14 Note: If the <<include>> use case has already been created and you simply want to connect the base use case with the existing <<include>> use case, then drop the <<include>> use case into the existing Find Member Record <<include>> use case. A dependency link between the base use case Register New Member and the <<include>> Find Member Record use case will then be created.
Chapter 3: Use Case Modeling and Analysis 14 Note: If the <<include>> use case has already been created and you simply want to connect the base use case with the existing <<include>> use case, then drop the <<include>> use case into the existing Find Member Record <<include>> use case. A dependency link between the base use case Register New Member and the <<include>> Find Member Record use case will then be created.
Step 9: Prioritize Use Cases We shall prioritize the use cases using the use case schedule.
Step 9: Prioritize Use Cases We shall prioritize the use cases using the use case schedule.
Figure 3.70. Use Case Schedule for the Mail Order System
Figure 3.70. Use Case Schedule for the Mail Order System
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved