Use CaseModeling: Context Diagram, Can you please help me make a usecase context diagram for the NexGen POS system based on the format of Larman figure 6.3 and referencing figures 6.4 and 6.5. Can you please use Larman chapter 6, especially 6.16 and 6.17.

Use Cases Figure 6.1. Sample UP artifact influence. Sample UP Artifact Relationships Domain Model Business Sale 1 Sales Modeling Lineltem date quantity Vision ) scope, goals, actors, features objects, attributes associations Use-Case Model Process Sale use 1. Customer case arrives... names 2. Cashier makes new sale. 3... Car terms, attributes validation Glossary Require- ments Use Case Diagram Use Case Text system events Supplementary Specification : System Operation: Cashier make enteritem(...) ystem New Sale() Post-conditions: operations enteritem (id quantity) Operation Contracts System Sequence Diagrams non-functional reqs. quality attributes requirements Design Model : Register Product Catalog : Sale Design enteritem (itemID, quantity) spec = getProductSpec itemID) addlineltem( spec, quantity) 6.1. Example Informally, use cases are text stories of some actor using a system to meet goals. Here is an example brier formal use case: Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a receipt from the system and then leaves with the items. 49 Use Cases Notice that use cases are not diagrams, they are text. Focusing on secondary-value UML use case diagrams rather than the important use case text is a common mistake for use case novices. UML use case diagrams p. 89 Use cases often need to be more detailed or structured than this example, but the essence is discovering and recording functional requirements by writing stories of using a system to fulfill user goals; that is, cases of use! It isn't supposed to be a difficult idea, although it's often difficult to discover what's needed and write it well. 6.2. Definition: What are Actors, Scenarios, and Use Cases? First, some informal definitions: an actor is something with behavior, such as a person (identified by role), computer system, or organization; for example, a cashier. A scenario is a specific sequence of actions and interactions between actors and the system; it is also called a use case instance. It is one particular story of using a system, or one path through the use case; for example, the scenario of successfully purchasing items with cash, or the scenario of failing to purchase items because of a credit payment denial. Informally then, a use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal. For example, here is a casual formar use case with alternate scenarios: Handle Returns Main Success Scenario: A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item... Alternate Scenarios: If the customer paid by credit, and the reimbursement transaction to their credit account is rejected, inform the customer and pay them with cash. If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the identifier code (perhaps it is corrupted). If the system detects failure to communicate with the external accounting system, ... Now that scenarios (use case instances) are defined, an alternate, but similar definition of a use case provided by the RUP will make better sense: A set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor [RUP]. 6.3. Use Cases and the Use-Case Model The UP defines the Use Case Model within the Requirements discipline. Primarily, this is the set of all written use cases; it is a model of the system's functionality and environment. Use cases are text documents, not diagrams, and use-case modeling is primarily an act of writing text, not drawing diagrams. The original term in Swedish literally translates as 'usage case." 50 Use Cases The Use-Case Model is not the only requirement artifact in the UP. There are also the Supplementary Speci- fication, Glossary, Vision, and Business Rules. These are all useful for requirements analysis, but secondary at this point. other UP requirements p. 101 The Use Case Model may optionally include a UML use case diagram to show the names of use cases and actors, and their relationships. This gives a nice context diagram of a system and its environment. It also provides a quick way to list the use cases by name. UML use case diagram p. 89 There is nothing object-oriented about use cases; we're not doing 00 analysis when writing them. That's not a problemuse cases are broadly applicable, which increases their usefulness. That said, use cases are a key requirements input to classic OOAD. 6.4. Motivation: Why Use Cases? We have goals and want computers to help meet them, ranging from recording sales to playing games to esti- mating the flow of oil from future wells. Clever analysts have invented many ways to capture goals, but the best are simple and familiar. Why? This makes it easierespecially for customersto contribute to their def- inition and review, That lowers the risk of missing the mark. This may seem like an off-hand comment, but it's important. Researchers have concocted complex analysis methods that they understand, but that send your average business person into a coma! Lack of user involvement in software projects is near the top of the list of reasons for project failure [Larman03], so anything that can help keep them involved is truly desirable. Use cases are a good way to help keep it simple, and make it possible for domain experts or requirement donors to themselves write (or participate in writing) use cases. more motivation p. 92 Another value of use cases is that they emphasize the user goals and perspective; we ask the question "Who is using the system, what are their typical scenarios of use, and what are their goals? This is a more user-centric emphasis compared to simply asking for a list of system features, Much has been written about use cases, and though worthwhile, creative people often obscure a simple idea with layers of sophistication or over-complication. It is usually possible to spot a novice use-case modeler (or a serious Type-A analyst!) by an over-concern with secondary issues such as use case diagrams, use case relationships, use case packages, and so forth, rather than a focus on the hard work of simply writing the text stories. That said, a strength of use cases is the ability to scale both up and down in terms of sophistication and formality. 6.5. Definition: Are Use Cases Functional Re- quirements? Use cases are requirements, primarily functional or behavioral requirements that indicate what the system will do. In terms of the FURPS+ requirements types, they emphasize the "F* (functional or behavioral), but can also be used for other types, especially when those other types strongly relate to a use case. In the UPand many modem methodsise cases are the central mechanism that is recommended for their discovery and definition FURPS+ p. 56 51 Use Cases Start the name of use cases with a verb. A common exception to one use case per goal is to collapse CRUD (create, retrieve, update, delete) separate goals into one CRUD use case, idiomatically called Manage For example, the goals edit user," "delete user," and so forth are all satisfied by the Manage Users use case. 6.16. Guideline: What Tests Can Help Find Use- ful Use Cases? Which of these is a valid use case? Negotiate a Supplier Contract Handle Returns Log In Move Piece on Game Board An argument can be made that all of these are use cases at different levels, depending on the system boundary, actors, and goals. But rather than asking in general, "What is a valid use case?", a more practical question is: "What is a useful level to express use cases for application requirements analysis?" There are several rules of thumb, including: The Boss Test The EBP Test The Size Test The Boss Test Your boss asks, "What have you been doing all day?" You reply: "Logging in!" Is your boss happy? If not, the use case fails the Boss Test, which implies it is not strongly related to achieving results of measurable value. It may be a use case at some low goal level, but not the desirable level of focus for requirements analysis. That doesn't mean to always ignore boss-test-failing use cases. User authentication may fail the boss test, but may be important and difficult The EBP Test An Elementary Business Process (EBP) is a term from the business process engineering field, defined as: A task performed by one person in one place at one time, in response to a business event, which adds mea- surable business value and leaves the data in a consistent state, e.g., Approve Credit or Price Order (original source lost), SEBP is similar to the term user task in usability engineering, although the meaning is less strict in that domain. 72 Use Cases Focus on use cases that reflect EBPs. The EBP Test is similar to the Boss Test, especially in terms of the measurable business value qualification The definition can be taken too literally: Does a use case fail as an EBP if two people are required, or if a person has to walk around? Probably not, but the feel of the definition is about right. It's not a single small step like "delete a line item" or "print the document." Rather, the main success scenario is probably five or ten steps. It doesn't take days and multiple sessions, like "negotiate a supplier contract"; it is a task done during a single session. It is probably between a few minutes and an hour in length. As with the UP's definition, it emphasizes adding observable or measurable business value, and it comes to a resolution in which the system and data are in a stable and consistent state. The Size Test A use case is very seldom a single action or step, rather, a use case typically contains many steps, and in the fully dressed format will often require 3-10 pages of text. A common mistake in use case modeling is to define just a single step within a series of related steps as a use case by itself, such as defining a use case called Enter an Item ID. You can see a hint of the error by its small sizethe use case name will wrongly suggest just one step within a larger series of steps, and if you imagine the length of its fully dressed text, it would be extremely short. Example: Applying the Tests Negotiate a Supplier Contract Much broader and longer than an EBP. Could be modeled as a business use case, rather than a system use case Handle Returns . OK with the boss. Seems like an EBP. Size is good. Log In Boss not happy if this is all you do all day! Move Piece on Game Board Single stepfails the size test. Reasonable Violations of the Tests Although the majority of use cases identified and analyzed for an application should satisfy the tests, exceptions are common It is sometimes useful to write separate subfunction-level use cases representing subtasks or steps within a regular EBP-level use case. For example, a subtask or extension such as "paying by credit" may be repeated in several base use cases. If so, it is desirable to separate this into its own use case, even though it does not really satisfy the EBP and size tests, and link it to several base use cases, to avoid duplication of the text. see the use case "include" relationship for more on linking subfunction use cases p. 494 73 Use Cases Authenticate User may not pass the Boss test, but be complex enough to warrant careful analysis, such as for a single sign-on" feature, 6.17. Applying UML: Use Case Diagrams The UML provides use case diagram notation to illustrate the names of use cases and actors, and the relation- ships between them (see Figure 6.3). Figure 6.3. Partial use case context diagram. system boundary NextGen POS communication Process Sale alternate notation for a computer system actor Customer Payment Authorization Service Handle Returns actor wactor Tax Calculator Cashier Cash In cactor Accounting System Manager Analyze Activity cactor HR System actory Sales Activity System Manage Security System Administrator Manage Users use case Use case diagrams and use case relationships are secondary in use case work. Use cases are text docu- ments. Doing use case work means to write text. A common sign of a novice (or academic) use case modeler is a preoccupation with use case diagrams and use case relationships, rather than writing text. World-class use case experts such as Fowler and Cockburn, among others, downplay use case diagrams and use case relationships, and instead focus on writing. With that as a caveat, a simple use case diagram provides a succinct visual context diagram for the system, illustrating the external actors and how they use the system. *Cash In" is the act of a cashier arriving with a drawer insert with cash, logging in, and recording the cash amount in the drawer insert. 74 Use Cases Guideline Draw a simple use case diagram in conjunction with an actor-goal list. A use case diagram is an excellent picture of the system context; it makes a good context diagram, that is, showing the boundary of a system, what lies outside of it, and how it gets used. It serves as a communication tool that summarizes the behavior of a system and its actors. A sample partial use case context diagram for the NextGen system is shown in Figure 6.3. Guideline: Diagramming Figure 6.4 offers diagram advice. Notice the actor box with the symbol actor. This style is used for UML keywords and stereotypes, and includes guillemet symbolsspecial single-character brackets (actor), not >) most widely known by their use in French typography to indicate a quote. Figure 6.4. Notation suggestions. For a use case context Show computer system actors diagram, limit the use cases to with an alternate notation to user-goal level use cases. human actors. NextGen Process Sale actor Payment Authorization Service Cashier primary actors on the left supporting actors on the right To clarify, some prefer to highlight external computer system actors with an alternate notation, as illustrated in Figure 6.5. Figure 6.5. Alternate actor notation. NextGen Process Sale -actone Payment Authorization Service system Payment Authorization Service Some UML alteratives to illustrate external actors that are other computer systems. The class box style can be used for any actor, computer or human. Using it for computer actors provides visual distinction Payment Authorization Service 75 Use Cases Figure 6.1. Sample UP artifact influence. Sample UP Artifact Relationships Domain Model Business Sale 1 Sales Modeling Lineltem date quantity Vision ) scope, goals, actors, features objects, attributes associations Use-Case Model Process Sale use 1. Customer case arrives... names 2. Cashier makes new sale. 3... Car terms, attributes validation Glossary Require- ments Use Case Diagram Use Case Text system events Supplementary Specification : System Operation: Cashier make enteritem(...) ystem New Sale() Post-conditions: operations enteritem (id quantity) Operation Contracts System Sequence Diagrams non-functional reqs. quality attributes requirements Design Model : Register Product Catalog : Sale Design enteritem (itemID, quantity) spec = getProductSpec itemID) addlineltem( spec, quantity) 6.1. Example Informally, use cases are text stories of some actor using a system to meet goals. Here is an example brier formal use case: Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a receipt from the system and then leaves with the items. 49 Use Cases Notice that use cases are not diagrams, they are text. Focusing on secondary-value UML use case diagrams rather than the important use case text is a common mistake for use case novices. UML use case diagrams p. 89 Use cases often need to be more detailed or structured than this example, but the essence is discovering and recording functional requirements by writing stories of using a system to fulfill user goals; that is, cases of use! It isn't supposed to be a difficult idea, although it's often difficult to discover what's needed and write it well. 6.2. Definition: What are Actors, Scenarios, and Use Cases? First, some informal definitions: an actor is something with behavior, such as a person (identified by role), computer system, or organization; for example, a cashier. A scenario is a specific sequence of actions and interactions between actors and the system; it is also called a use case instance. It is one particular story of using a system, or one path through the use case; for example, the scenario of successfully purchasing items with cash, or the scenario of failing to purchase items because of a credit payment denial. Informally then, a use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal. For example, here is a casual formar use case with alternate scenarios: Handle Returns Main Success Scenario: A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item... Alternate Scenarios: If the customer paid by credit, and the reimbursement transaction to their credit account is rejected, inform the customer and pay them with cash. If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the identifier code (perhaps it is corrupted). If the system detects failure to communicate with the external accounting system, ... Now that scenarios (use case instances) are defined, an alternate, but similar definition of a use case provided by the RUP will make better sense: A set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor [RUP]. 6.3. Use Cases and the Use-Case Model The UP defines the Use Case Model within the Requirements discipline. Primarily, this is the set of all written use cases; it is a model of the system's functionality and environment. Use cases are text documents, not diagrams, and use-case modeling is primarily an act of writing text, not drawing diagrams. The original term in Swedish literally translates as 'usage case." 50 Use Cases The Use-Case Model is not the only requirement artifact in the UP. There are also the Supplementary Speci- fication, Glossary, Vision, and Business Rules. These are all useful for requirements analysis, but secondary at this point. other UP requirements p. 101 The Use Case Model may optionally include a UML use case diagram to show the names of use cases and actors, and their relationships. This gives a nice context diagram of a system and its environment. It also provides a quick way to list the use cases by name. UML use case diagram p. 89 There is nothing object-oriented about use cases; we're not doing 00 analysis when writing them. That's not a problemuse cases are broadly applicable, which increases their usefulness. That said, use cases are a key requirements input to classic OOAD. 6.4. Motivation: Why Use Cases? We have goals and want computers to help meet them, ranging from recording sales to playing games to esti- mating the flow of oil from future wells. Clever analysts have invented many ways to capture goals, but the best are simple and familiar. Why? This makes it easierespecially for customersto contribute to their def- inition and review, That lowers the risk of missing the mark. This may seem like an off-hand comment, but it's important. Researchers have concocted complex analysis methods that they understand, but that send your average business person into a coma! Lack of user involvement in software projects is near the top of the list of reasons for project failure [Larman03], so anything that can help keep them involved is truly desirable. Use cases are a good way to help keep it simple, and make it possible for domain experts or requirement donors to themselves write (or participate in writing) use cases. more motivation p. 92 Another value of use cases is that they emphasize the user goals and perspective; we ask the question "Who is using the system, what are their typical scenarios of use, and what are their goals? This is a more user-centric emphasis compared to simply asking for a list of system features, Much has been written about use cases, and though worthwhile, creative people often obscure a simple idea with layers of sophistication or over-complication. It is usually possible to spot a novice use-case modeler (or a serious Type-A analyst!) by an over-concern with secondary issues such as use case diagrams, use case relationships, use case packages, and so forth, rather than a focus on the hard work of simply writing the text stories. That said, a strength of use cases is the ability to scale both up and down in terms of sophistication and formality. 6.5. Definition: Are Use Cases Functional Re- quirements? Use cases are requirements, primarily functional or behavioral requirements that indicate what the system will do. In terms of the FURPS+ requirements types, they emphasize the "F* (functional or behavioral), but can also be used for other types, especially when those other types strongly relate to a use case. In the UPand many modem methodsise cases are the central mechanism that is recommended for their discovery and definition FURPS+ p. 56 51 Use Cases Start the name of use cases with a verb. A common exception to one use case per goal is to collapse CRUD (create, retrieve, update, delete) separate goals into one CRUD use case, idiomatically called Manage For example, the goals edit user," "delete user," and so forth are all satisfied by the Manage Users use case. 6.16. Guideline: What Tests Can Help Find Use- ful Use Cases? Which of these is a valid use case? Negotiate a Supplier Contract Handle Returns Log In Move Piece on Game Board An argument can be made that all of these are use cases at different levels, depending on the system boundary, actors, and goals. But rather than asking in general, "What is a valid use case?", a more practical question is: "What is a useful level to express use cases for application requirements analysis?" There are several rules of thumb, including: The Boss Test The EBP Test The Size Test The Boss Test Your boss asks, "What have you been doing all day?" You reply: "Logging in!" Is your boss happy? If not, the use case fails the Boss Test, which implies it is not strongly related to achieving results of measurable value. It may be a use case at some low goal level, but not the desirable level of focus for requirements analysis. That doesn't mean to always ignore boss-test-failing use cases. User authentication may fail the boss test, but may be important and difficult The EBP Test An Elementary Business Process (EBP) is a term from the business process engineering field, defined as: A task performed by one person in one place at one time, in response to a business event, which adds mea- surable business value and leaves the data in a consistent state, e.g., Approve Credit or Price Order (original source lost), SEBP is similar to the term user task in usability engineering, although the meaning is less strict in that domain. 72 Use Cases Focus on use cases that reflect EBPs. The EBP Test is similar to the Boss Test, especially in terms of the measurable business value qualification The definition can be taken too literally: Does a use case fail as an EBP if two people are required, or if a person has to walk around? Probably not, but the feel of the definition is about right. It's not a single small step like "delete a line item" or "print the document." Rather, the main success scenario is probably five or ten steps. It doesn't take days and multiple sessions, like "negotiate a supplier contract"; it is a task done during a single session. It is probably between a few minutes and an hour in length. As with the UP's definition, it emphasizes adding observable or measurable business value, and it comes to a resolution in which the system and data are in a stable and consistent state. The Size Test A use case is very seldom a single action or step, rather, a use case typically contains many steps, and in the fully dressed format will often require 3-10 pages of text. A common mistake in use case modeling is to define just a single step within a series of related steps as a use case by itself, such as defining a use case called Enter an Item ID. You can see a hint of the error by its small sizethe use case name will wrongly suggest just one step within a larger series of steps, and if you imagine the length of its fully dressed text, it would be extremely short. Example: Applying the Tests Negotiate a Supplier Contract Much broader and longer than an EBP. Could be modeled as a business use case, rather than a system use case Handle Returns . OK with the boss. Seems like an EBP. Size is good. Log In Boss not happy if this is all you do all day! Move Piece on Game Board Single stepfails the size test. Reasonable Violations of the Tests Although the majority of use cases identified and analyzed for an application should satisfy the tests, exceptions are common It is sometimes useful to write separate subfunction-level use cases representing subtasks or steps within a regular EBP-level use case. For example, a subtask or extension such as "paying by credit" may be repeated in several base use cases. If so, it is desirable to separate this into its own use case, even though it does not really satisfy the EBP and size tests, and link it to several base use cases, to avoid duplication of the text. see the use case "include" relationship for more on linking subfunction use cases p. 494 73 Use Cases Authenticate User may not pass the Boss test, but be complex enough to warrant careful analysis, such as for a single sign-on" feature, 6.17. Applying UML: Use Case Diagrams The UML provides use case diagram notation to illustrate the names of use cases and actors, and the relation- ships between them (see Figure 6.3). Figure 6.3. Partial use case context diagram. system boundary NextGen POS communication Process Sale alternate notation for a computer system actor Customer Payment Authorization Service Handle Returns actor wactor Tax Calculator Cashier Cash In cactor Accounting System Manager Analyze Activity cactor HR System actory Sales Activity System Manage Security System Administrator Manage Users use case Use case diagrams and use case relationships are secondary in use case work. Use cases are text docu- ments. Doing use case work means to write text. A common sign of a novice (or academic) use case modeler is a preoccupation with use case diagrams and use case relationships, rather than writing text. World-class use case experts such as Fowler and Cockburn, among others, downplay use case diagrams and use case relationships, and instead focus on writing. With that as a caveat, a simple use case diagram provides a succinct visual context diagram for the system, illustrating the external actors and how they use the system. *Cash In" is the act of a cashier arriving with a drawer insert with cash, logging in, and recording the cash amount in the drawer insert. 74 Use Cases Guideline Draw a simple use case diagram in conjunction with an actor-goal list. A use case diagram is an excellent picture of the system context; it makes a good context diagram, that is, showing the boundary of a system, what lies outside of it, and how it gets used. It serves as a communication tool that summarizes the behavior of a system and its actors. A sample partial use case context diagram for the NextGen system is shown in Figure 6.3. Guideline: Diagramming Figure 6.4 offers diagram advice. Notice the actor box with the symbol actor. This style is used for UML keywords and stereotypes, and includes guillemet symbolsspecial single-character brackets (actor), not >) most widely known by their use in French typography to indicate a quote. Figure 6.4. Notation suggestions. For a use case context Show computer system actors diagram, limit the use cases to with an alternate notation to user-goal level use cases. human actors. NextGen Process Sale actor Payment Authorization Service Cashier primary actors on the left supporting actors on the right To clarify, some prefer to highlight external computer system actors with an alternate notation, as illustrated in Figure 6.5. Figure 6.5. Alternate actor notation. NextGen Process Sale -actone Payment Authorization Service system Payment Authorization Service Some UML alteratives to illustrate external actors that are other computer systems. The class box style can be used for any actor, computer or human. Using it for computer actors provides visual distinction Payment Authorization Service 75