1 / 9

Optimizing Use Cases for Effective Domain Model Refinement

Learn to relate use cases efficiently and avoid analysis paralysis. Understand use case terminology and refine them effectively using concrete, abstract, base, include, and extend concepts. Discover how to update use cases for better process modeling.

egrossman
Télécharger la présentation

Optimizing Use Cases for Effective Domain Model Refinement

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Week 11 Iteration 3 Relating Use Cases Domain Model Refinement SSD and Contracts

  2. Chapter 30 Relating Use Case

  3. Avoid agonizing over use cases • Use cases can be related, have common subtasks • While useful - this can waste time! • “Analysis paralysis” • Write the use cases first • Find obvious relations as you go, when they make sense and help • Don’t agonize over getting it perfect. • “A good plan now is worth a perfect plan in the indefinite future.” - George Patton

  4. Use Case Terminology • Concrete - performs an entire action • Abstract - use cases that cannot standalone - part of another use case • Base - Use cases that include other use cases

  5. Include • Allows dividing use cases into sub use cases • Can decompose a complex use case • Asynchronous events • Under extensions * mark async actions • Use include to separate out details • Include is a “pointer” from the original use case to something new.

  6. Extend • For baselined use cases • Used when the initial use cases cannot be changed. • Inherited from another project • Not worth going back to update and change • Baselined • Documents an earlier version • Does not have a pointer from the original use case.

  7. Fig. 30.1 Process Sale and the new Process Rental are updated to include the various payment types.

  8. Fig. 30.2 Process Sale does not have a “gift certificate” state.

  9. Summary • Tweaks on use cases • Why are we coming back to use cases? • When you learn a new process, you have to jump in somewhere along the cycle. • Not clear what to do until you have a view of the entire cycle. • Once the overall structure is in place, come back and fill in some of the details

More Related