The distinction between > and > should also be understood. In a similar vein, placing an order on the website in this example, requires creating an account first. The base use case "place order" thus uses the "select item" use case. Placing an order requires the customer to first select an item. I'll now use an e-commerce site as an example. An extension is functionally identical to an alternate flow, but is captured in a separate use case for convenience. The base use case is completely functional on its own and can do without the extending use case. This can be achieved by “pay by credit card”, “pay cash on delivery” or “pay by PayPal”.Īccording to BABOK V2, "extends" allows the analyst to demonstrate additional behaviour of the base use case. Think of a use case called “pay for item”. You may choose to insert a boundary across the use case diagram to indicate the system functionalities that fall within that boundary.Ī common confusion with use case diagramming is the difference between > and >. I like to define "extends" as an optional functionality.The > and > text when added to a relationship and drawn from A to B means that doing A involves doing B at least once.It is usually represented as a combination of a verb and a noun, e.g. “deliver product”, “prepare invoice”, etc. A use case is the action that is performed within the system.
They are usually modelled as being external to the system boundary. For example, a customer, a restaurant, or database can be referred to as actors. An actor can be a person, company, gadget, software or external entity that interacts with your system.It’s a technique for specifying functional requirements.īecause use cases are easier to draw (when compared with other UML models), I'll just provide a guideline of the rules to follow and some examples below: USE CASE DIAGRAM - Includes Free TemplateĪ use case diagram provides a high-level description of what your system should be able to do and who/what will interact with it.
0 kommentar(er)
