This week's book giveaway is in the General Computing forum. We're giving away four copies of Arduino in Action and have Martin Evans, Joshua Noble, and Jordan Hochenbaum on-line! See this thread for details.
In the Cade & Roberts SCJEA study guide, the case study example gives us a business domain object model (shown on page 160), and tells us that: "This is an accurate representation of the system and you cnanot modify or change it in any way. You might not agree with the analyst, but you must use this representation of the system." This is very similar to the actual SCJEA project requirement. The Cade&Robert solution to their sample design problem includes a class diagram (shown on page 169). The author writes: "The class diagram is a little different from the Business Domain Object Model (BDOM) provided by the business analyst, but it provides additional details and still meets the requirements of the BDOM. ... Manufacturer is no longer an object, it is now an attribute of Product. In addition, an Order no longer has a direct relationship to Product, it must use LineItem to form the relationship." Excuse me, but exactly how are these changes not in violation of "... you cannot modify or change it (the BDOM) in any way ... you must use this representation of the system." If that doesn't count as a change or modification of the BDOM, then what would??? What exactly is meant by "you cannot modify or change it"???
Hello Frank, I interpreted "not breaking the Business Domain Object Model" to mean basically maintaining the same multiplicity for the relationships. In the assignment I think maintaining the multiplicity of the relationships is the most important thing. You can add the "this is a part of that" (aggregation), "this is linked to that" (association) wherever you want as long as you justify it. But if you break the multiplicity then you break the BDOM. In the Cade example they are not breaking the BDOM they are supplying the implementation details. If you didn�t refine the BDOM you would end up submitting this as a class diagram. Ian
At times I wonder if "You must not Change It" means they have made a simplification to the business model and they want you to use it. A real reservation system is more complicated than they can grade. Historically people that admitted to having abandoned the BDOM have reported high scores.
Joined: Jun 06, 2002
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?