Figure 1. Strategies for
iterating to another artifact.
|Interesting implications of the diagram:
- You have multiple models to choose from.
- There is no starting point.
- Development is serial in the large. You can
see this in the fact that the left side of the
diagram are mostly requirements artifacts, that as
you proceed towards the right that the artifacts
focus on analysis, then design, then finally code.
- Development is iterative in the small. On
any given day I am likely to work on several
artifacts and will iterate back and forth between
UML doesn't provide a complete picture,
instead you need to take a more realistic
look at it.
- No one model or artifact "drives"
another. A common myth is that your data
schema should drive your object schema (and vice
versa). Instead you need to be prepared to
strategies depending on your situation.
- This diagram is arguably a high-level meta model
relating development artifacts that implies
traceability strategies for your team.
- What I'm really talking about is "modeling
normalization" -- using each artifact for what
it is good for and referring to information in other
models (e.g. a use case refers to a business rule)
but not copying that information. This approach
ensures highly cohesive models that are loosely
coupled to one another.
Figure 2, taken from
Development Phases Examined,
shows the various categories of models and how you
iterate back and forth between them as needed.
It's basically an update, and generalization, of
Figure 2. Categories of models.
If you're trying to print this, you'll likely need to
print it in landscape mode.