For example, a normal “purchase item” use case might be extended with additional functionality enable a user to purchase an item that is not in stock, to be a “purchase out of stock item”. An Extend Relationship indicates that the functionality of one use case is extended by adding new behaviors or actions, resulting in an expanded version of the original use case.There are two different types of relationships, the Extend relationship and the Include relationship. The relationships between different use cases. An example of the simple line option is below: In some cases it is by a simple line (not an arrow) between the actor and any use cases they directly interact with and in other cases it is a solid line arrow leading from the initiating actor to the use case or from the use case to any participating or benefiting actors. There seem to be two different standards for how Associations are represented. These associations indicate that the use case will be initiated by the actor(s), or that they participate in the Use Case or benefit from it. Sometimes also referred to as Connections. The associations between actors and use cases. Use cases are represented in the diagram by ellipse like this: They are what an Actor would like the system to do and are usually named in the form of a present tense verb+object pair, such as “Update Inventory”, “Hire Employee”, “Order Food”, and similar names. These are high-level functions that will be further documented in the form of the textual use cases, not diagrams. Human actors are generally represented by stick figures while system actors are generally represented by rectangles with the other system name enclosed in double triangle brackets (i.e. Actors can also be other systems that interact with the system being modeled. For example, an Actor would be “Student”, but not “Bill Jones”, and probably not even “12 th Grade Student”. Actors are always placed outside the system boundary and represent general roles, not specific individuals. The actors who interact with the functions of the system being modeled. The system name is commonly added just inside the top border of the rectangle. The system is generally represented as simple rectangle into which the use cases are placed.
Use Case Diagrams are made up of five standard components. It is one of the most-widely use UML models and most business analysts should be familiar enough with them to at least use them casually. Originally developed by Ivar Jacobson when he was still at Erickson, a Use Case Diagram is a visual model that depicts key system functions accessed by those outside the system and the actors that interact with those functions. If you wonder what I suggest as an alternative, please see my blog post: Do We Really Need Use Case Diagrams? I have done my best to make it accurate though, and my sources are documented at the bottom. And because I don't use them much, it is entirely possible that there are mistakes in this wiki article. Use Case Diagrams DISCLAIMER: I am not a big fan of Use Case Diagrams.
0 kommentar(er)
