![]() The arrow points from the extension to the base. To show extend relationship, the extension connects to the base with an open arrow. Oh, and in the case that reserve is an extension of borrow, don't draw it like you did in your diagram. Otherwise, yes, it is an extension of borrow because it executes only when borrowing a book that is unavailable. A member can make a reservation without having to borrow. If a member can make a reservation independently (for whatever reason) even if the book is available (like he reached his borrowing limit), then no, reservation cannot be the extend of borrow. Use an extension relation when one use case has behavior that is optional, or when it has a behavior that executes only under some conditions.Ĭould the reservation be the extend of borrow? ![]() In general what are rules of thumb to find out extension relation? This is not the case for the extension-it depends on the base. In extend relationships, the base is independent and meaningful by itself. The former is the extension, and the latter is the base. There is an extension relationship if one use case extends the behavior of another. I have problem to understand the extension relation in the use caseĭiagrams, sometimes some relations seem extension. I happen to come across this lately while studying about OO design. I believe this is more in line with the functionality you are describing in your question. The implementation details are left as an exercise for additional specification, but this indicates that the in order to either check out a book or place a reservation, the librarian must first look up the book. Both checking out books and recording reservations use the look up book use case, but add additional behaviors. In this example, the Librarian can perform three functions - looking up books, checking out books, and recording reservations. I'm not sure that this is what you are going for. However, the search functionality is not available as a stand-alone entity. Both examples require the librarian to look up the book using the information provided by the member. In this example, the Librarian can perform two functions - check out a book or reserve a book. ![]() It appears that the person actually interacting with the software is not the library member, but the librarian. In both, I changed the actor from "Member" to "Librarian". Looking at your particular example, I developed two use case models that I feel are more appropriate. In this type of relationship, the included use case is usually not available as a stand-alone use case. The specific behavior is not important, but the end result is, which means that the included use case could have a different implementation, but the same steps and end result. The include relationship is used when one use case includes the functionality of another use case. This also indicates some level of reuse between the features. Note that it's not required that an extension actually be executed - it's just a possibility. Then, depending on what happens during execution of that one use case, one or more other use cases could possibly be executed. In this situation, the base case would be executed. The extend relationship is used when one use case adds behavior to another use case. There are two relationships in a use case diagram - include and extend.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |