Oct
17
«include» and «extend»
October 17, 2005 |
These stereotypes tend to cause great pain to people developing use case models. While the technical definitions are complex, the actual practical uses are simple enough.
«include» should be used when you have functionality common to multiple use cases. The included use case will be something like Authenticate User. The calling use case goes off, executes the included case, and then returns to its flow.
«extend» should be used when you are building on a use case that you developed in a prior release. It is nothing more than an alternate flow that has been given its own use case, generally because it can be implemented seperately. The extending use case shoud deal with whatever problem it has been created to handle without impacting the use case which it extends.
Simple enough?
Comments
1 Comment so far
What I'm Reading- Enterprise Agility-The Big Picture (7): Vision and Release BacklogScaling Software Agility
- A New Agile PM Book?Herding Cats
- Dear ManagerTrials & Tribulations of a Business Systems Analyst
- What is requirements management?Business Analyst Blog
- Gartner and the Hype Cycle of Emerging TechnologiesCTO Blog
- It’s All About the FeedbackRuminations
- Who should lead SOA? Enterprise architects or business analysts?Service-Oriented Architecture
- Learning to say “No”EDS' Next Big Thing Blog: Read and Respond to What the EDS Fellows Say About Technology
- Learning About Process Case Study - Business ProblemTrials & Tribulations of a Business Systems Analyst
- 12 early warning signs of IT failureIT Project Failures
O’ friend u caused me a great headache cause these fucking stereo types
plz email me and make me understand extend&include relationship
god bless u