3.05_The ''extend'' Dependency

rmb1905
10 Mar 200903:53

Summary

TLDRThis video explains the concept of the 'extend' dependency in use case diagrams, highlighting how it represents an optional relationship between two use cases: the base use case and the extending use case. The extending use case adds new behavior to the base use case, without being essential for its completion. The video uses an example of purchasing gas with a credit card and optionally printing a receipt to illustrate the concept. It also discusses the importance of using extensions sparingly to avoid clutter in diagrams and considering them for later implementations when on a tight schedule.

Takeaways

  • πŸ˜€ The extended dependency indicates an optional relationship between two use cases, where one expands the behavior of the other.
  • πŸ“‹ There is a base use case and an extending use case in this relationship, where the extending use case adds additional steps to the base.
  • ↔️ The direction of the dependency arrow shows the extending use case depends on the base use case.
  • πŸ“‰ It's conventional to draw the extending use case below the base use case in diagrams.
  • πŸ’³ In a gas purchase example, the 'Purchase gas with credit card' is the base use case, and 'Print receipt' is the extending use case.
  • πŸ”„ Extension points indicate where the extending use case happens in the base use case, although they aren't always necessary.
  • ⏳ The extending use case can occur synchronously (within the base use case steps) or asynchronously (in parallel).
  • πŸ›  Use extensions sparingly to avoid cluttering diagrams and making them hard to read.
  • πŸ“Š Extension use cases are secondary, focusing on optional steps that are not critical to the base use case's completion.
  • πŸ“… Extension use cases are good candidates for later implementations if working on a tight schedule.

Q & A

  • What is an extended dependency in use case relationships?

    -An extended dependency is an optional relationship between two use cases where one use case (the extending use case) expands the behavior of another use case (the base use case) by adding new steps.

  • How does the direction of the dependency arrow work in an extended relationship?

    -The direction of the dependency arrow goes from the extending use case to the base use case, indicating that the extending use case depends on the base use case.

  • What is the purpose of an extending use case?

    -The extending use case adds new steps to the base use case, expanding its behavior, though the base use case can still function without the extending use case.

  • What is an example of an extended use case in real life?

    -An example is purchasing gas with a credit card (base use case) and having the option to print a receipt (extending use case). The transaction can be completed without printing a receipt, but the option to do so is available.

  • Where does the extending use case typically appear in a diagram?

    -In a diagram, the extending use case usually appears below the base use case for clarity.

  • What is the role of an extension point in a use case diagram?

    -An extension point indicates where in the base use case the extending use case comes into play, marking the logical place for the extension, such as after a gas purchase is charged in the gas purchase example.

  • Are extension points mandatory in use case diagrams?

    -No, extension points are optional. While they can be helpful, they aren't always necessary and may be omitted if they clutter the diagram.

  • Can an extension use case happen asynchronously?

    -Yes, an extension use case can happen either synchronously within the steps of the base use case or asynchronously, meaning it could occur in parallel.

  • Why should extensions be used sparingly in use case diagrams?

    -Extensions should be used sparingly to avoid cluttering the diagram with too much information, which can make it hard to read and understand.

  • Are extension use cases considered secondary, and why?

    -Yes, extension use cases are considered secondary because they provide additional functionality that is not essential to the base use case. They are often implemented later if the schedule allows.

Outlines

plate

This section is available to paid users only. Please upgrade to access this part.

Upgrade Now

Mindmap

plate

This section is available to paid users only. Please upgrade to access this part.

Upgrade Now

Keywords

plate

This section is available to paid users only. Please upgrade to access this part.

Upgrade Now

Highlights

plate

This section is available to paid users only. Please upgrade to access this part.

Upgrade Now

Transcripts

plate

This section is available to paid users only. Please upgrade to access this part.

Upgrade Now
Rate This
β˜…
β˜…
β˜…
β˜…
β˜…

5.0 / 5 (0 votes)

Related Tags
Use CaseExtended DependencySystem DesignDiagramsSoftware DevelopmentUMLUse Case DiagramDependency ArrowExtension PointBase Use Case