posted 21 years ago
The advice of Ian and Rufus are probably exactly what one must do to get through this project, and I'm going to follow their advice.
But I wonder. If I were writing the requirements I would have said explicitly, "Don't change the multiplicities of the relationships in the BDOM" and "Don't use realism as an excuse to add complexity that's not required to fulfil the explicitly-given requirements."
To me the command "Don't change or modify the Business Domain Model in any way, even if you disagree" suggests that -- aside from whatever else you add to BDOM in constructing the class diagram -- every class in the BDOM must be a class in the class diagram, and every link in the BDOM must be an association in the class diagram. But that clearly won't work.
I mean, what exactly _is_ a Business Domain Model in UML, if not a subset of the Class Diagram?
Or does UML explicitly posit a looser relationship between BDOM and Class Diagram than I am assuming?
Or were the examiners' requirements deliberately contradictory? Do you think they're trying to get across some sort of social lesson -- that a software architect is sometimes given impossible requirements, and rather than pointing out and resolving the contradiction, corporate politics sometimes requires that we simply say, "Yes, sir" and then quietly disobey so we can accomplish that which really needs doing?