Str#1d. “Invest an Hour” Strategy // activities and model components
– Rather than philosophize endlessly, invest an hour in each of several different ways of modeling a particularly challenging area. Compare your results — and decide which way to go (based upon actual results, rather than the outcome of a multiweek debate).
Str#1e. “Consider the Domain First, Artifacts After That” Strategy // activities and model components
– Build an object model with a domain expert first. Then add-in content that you can extract from artifacts (existing data models, source code, whatever).
– Reason why: you need the benefit of the former (fresh insights, new ideas) to help you grapple with the latter (what to include, what to exclude).
Str#1f. “Extract Useful Content From An Existing Data Model” Strategy // activities and model components
– Yes, it can be done.
– Best practice: build an initial object model with a domain expert first. Then use that model to help you filter out the classes and attributes (in an previous data model) that are no longer needed. Why: the added domain understanding will help you do a better job leaving unneeded things behind, rather than dragging everything from the past along with you once again.
– For the entities:
. List them. Delete correlation tables. Delete (or revise) names that do not fit the problem domain vocabulary (words that a domain expert uses and understands). Collapse supertypes-subtypes that do not express domain-based generalization-specialization.
– Then, when you work on attributes:
. List them. Delete (or revise) names that do not fit the problem domain vocabulary (words that a domain expert uses and understands). Delete flags, indicators, sequence numbers, and unique keys — nearly all of which are simply leftover implementation mechanisms from a previous system.
-- EOF --
Today on history: