Mukesh Joshi

Greenhorn
+ Follow
since Feb 05, 2002
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mukesh Joshi

Package diagram shows logical grouping of classes along with package dependencies. So when you are designing a new system you should organize your classes into packages in such a way that there is scope for deciding buy or build or contract out for each package later.
Hope this helps.
I was wrong. I agree with YingTang that the InventoryProduct class has a collection of PhysicalProduct objects as an attribute.
I don't agree with Ram's statement "Inventory product object is a general representation of the product. When it comes to damaged goods, they become special types of products." Its just that the PhysicalProduct class adds more detail to InventoryProduct class and there could be many PhysicalProducts associated with one InventoryProduct.
[ March 07, 2002: Message edited by: Mukesh Joshi ]
Some method of class of object A invokes a method "check()" on an object B. The method "check" returns a boolean value "hasStock".
The class of object B would have a method like:
public Boolean check() {
Boolean hasStock := false;
// some code
...
return hasStock;
}

Hope this helps.
I think the answer should be A. Atleast I would do it that way.
I think it would be the package diagram.
If you didn't have a preferred supplier how would the anInventoryProduct select "the" supplier from a list of many suppliers ?
Since the diagram does not indicate selection of a specific supplier from the list of suppliers I still think that the answer is C.
Good point but ...
The relationship between InventoryProduct and Supplier is many-to-many. This means that the InventoryProduct object has to select a Supplier from a list of suppliers before it can send any message to it. How would the InventoryProduct object identify its supplier ?
But if we assume that the InventoryProduct somehow knows its preferred supplier then it can directly send a message without going through a selection process.
I would vote for Preferred Supplier instead of Supplier since there is a possibility that the Supplier class is abstract and one cannot instantiate abstract classes. On interaction diagrams one would normally expect to see only instantiated objects.
Am I right ? Makes sense but I am not sure.
How about using local interface for dependent entity EJBs ?
Has anybody compared performance using local interface vs using dependent objects.
"Even if you begin to capture use cases at a high level for a small system, those uses cases would eventually break down into smaller use cases representing a higher level of detail for each use case."
A high-level use case need not break down into smaller use cases when you start capturing higher level of detail. A high-level use case would break down into smaller use cases if there was common/shared functionality with other use cases and we would then factor out the common (include) use cases. Its important to remember that we are not doing functional decomposition when we start refining the use cases.
"But adjusting the level of detail is a good way to alter the outcome of how many uses cases you will generate from the analysis stage." It reminds me of a project manager I worked with a few years back. It doesn't make sense -- "that if there are more use cases then we capture the high-level details and if there are less then we capture more details ". Its always important to start to capture use cases at a high-level so we don't get lost in the detail and leave out important use cases. But sooner or later you have to capture the details. On a large project, one would capture the use cases at a high-level in the inception phase. A few important/complex UCs may be detailed out to get a proper estimate of the required effort. Each of the following iterations would involve analysis, design, construction and testing of a selected number of use cases. Its difficult but in an OO approach, distinction between A&D are blurred. It just what the focus (what or how) is that decides whether we are analyzing or designing.
Right?
Activity diagram can be used to show method implementation. See UML Distilled pg 167 - Appendix A - Techniques and their uses.
Hi!
I think the answer to Q17 should be A. Why is C true ?
---------
17) In design #1, the Catalog object has a getProducts() method, which returns a collection object, such as a Dictionary or array, containing all the Products the company sells. In design #2, the Catalog object has a getProductNumbered(anIdentifier) method, which returns the Product with the specified unique identifier. Considering the objects returned, which of the following BEST characterizes the two designs?
a) Both designs maintain the objects' encapsulation and reduce coupling by accessing state data via methods only and not directly.
b) Both designs break the objects' encapsulation, adding brittle coupling.
c) Design #1 breaks the encapsulation of the Catalog, adding brittle coupling. Design #2 maintains the encapsulation of the Catalog, making future design changes easier.
Single Select - Please select the best answer (one and only one choice must be selected).
Answer: C
--------------