This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
Hi, I have the following questions from IBM mock test. I have the answers from previous posts on this site. But, I did not understand the answers to the following questions. I appreciate if someone would explain these answers. 1. What are the systems’s actors in the diagram, Figure Use Case? a. Clerk, Manager b. Clerk, Manager, Customer c. Clerk, Manager, Bank network d. Clerk, Manager, Bank network, Customer Correct answer is d. In the exhibit, Customer is not linked to any of the use cases. My question is, if an actor is not linked to any of the use cases, how do we know if he is a valid actor? 2. When creating a subclass, the: a. selected superclass should be chosen because it has some methods the subclass can reuse, even if others do not apply. b. Class name should normally be a qualification of its superclasses’ name c. Subclass should be of the same type as all of its superclasses d. Superclass should be marked as abstract Correct answer is B and C. I understood that C should be the answer. To some extent, I understand why A is incorrect: since it is a ‘is a’ relationship, all the methods of superclass should be reused by subclass. Please correct me if this is not the reason why A is incorrect. But can somebody explain why B is the correct answer?Usually (like in Java), class name is pre-fixed by its package name, not its superclass ! Can you give an example where A applies? 3. In an OO system, it is desirable to assign responsibilities: a. relatively evenly across the classes. b. More heavily in a few controlling classes. c. According to interaction diagram messaging. Correct answers are A and C. Can somebody explain why A is correct and B is incorrect? Thanks
MM Koppula<br />SCJP2<br />Object Oriented Analysis and Design with UML (IBM)
Hi I have a disagreement with your answer to 1) the answer is c) if the actor does not interact with the system they do not play a role in the use case therefore they are not a valid actor. I don't have an answer for your second question But for the third question if you have a few classes controlling all the responsibilites aren't your classes going to be bloated and over worked. You distribute responsibilities so that the classes have high cohesion. If you have a few classes controlling all the responsibilities cohesion would be low. This is my opinion based on what I have read and been taught
Doug I have a disagreement with your answer to 1) the answer is c) if the actor does not interact with the system they do not play a role in the use case therefore they are not a valid actor. I thought the same way. But, the correct answer is d (from previous posts from people who got 100%. See Sandeep Desai's mails). But for the third question if you have a few classes controlling all the responsibilites aren't your classes going to be bloated and over worked. You distribute responsibilities so that the classes have high cohesion. If you have a few classes controlling all the responsibilities cohesion would be low. I agree that classes should have high cohesion and low coupling. But how will distributing responsibilities evenly among classes achieve this. Interactions among objects should drive the assignment of responsibilities. If we try to distribute the responsibilities evenly, wouldn't the classes have high coupling? On the other hand, by the nature of their functionality, I would assume that the controlling classes would have more responsibilites which would maintain their cohesiveness. Since my answers were wrong, I know somewhere my reasoning is at fault. I dont know where
I believe as you decompose an OO system x number of concepts develop which represent classes. A practical number of classes should be able to achieve both low coupling and high cohesion. With this train of thought responsibilities would be assigned relatively evenly across classes. Larmans video helped me understand this alot better
Merlin M Koppula
Joined: Jan 18, 2002
Todd, Larmans video helped me understand this alot better Can you please point me to the chapters in Larmans book where he discusses this point. Thanks.
Let me preface my response by saying I haven't passed 486, yet. For #2, the reason A is, I believe, twofold. First, you shouldn't subclass just to reuse methods. Subclassing is about refining the behavior of a superclass. In terms of behavior and responsibility, a subclass should have identical behavior as its superclass, and at least the same responsibilities (from the Liskov Substitution Principle). A subclass doesn't just "use" methods of its superclass. Another (more subtle) problem with A is the thought process involved when deciding what/how to subclass. Subclassing doesn't involve first coming up with a subclass then finding a home (a superclass) for it simply to resue methods. It involves noticing similar behavior among a set of classes, and then devloping a class hierarchy among those classes. That might be way off base, but that's what went through my head when I read the problem. I'd love to hear if anyone has any other ideas. As for B, what I think they're trying to get at is the fact that subclass behavior is more refined that its superclass. For example, you could have a superclass called "Payment" and three subclasses - "CreditCardPayment", "CashPayment", and "CheckPayment". Though, syntatically, you don't need to name subclasses in this fashion, I believe this is what the question is driving at.
Merlin M Koppula
Joined: Jan 18, 2002
Thank you michael. Your answer helps. I think pre-fixing superclass name for the subclass is more of a style than syntax in the context of this question. I wonder why this was not hinted in the question (like 'it is BEST to..).