Navigability on Cade's Case Study Class Diagram

[Ted Bell]

Hi all,
Was looking at the class diagram in Cade's study guide (the one at the end in the case study - figure 8-6).
Between Order and Customer, he indicates a single directional with the arrow on the Customer end. If I understand correctly, this means that the Order class has an instance variable of type Customer. But the Customer has no knowledge of what Orders are associated with it. Does this imply then that there is no way to tell what orders a customer has placed?
Maybe this is intentional, as I see nothing in the requirements about listing a customer's orders. Just wanted to make sure I understood correctly.
I have the same question about the Address and Customer relationship. An Address seems to know what Customer it belongs to, but a Customer instance does not have a variable of type Address? Is this to imply that rather than having a getAddress() method on Customer to get his Address, we would create a new Address, passing in our Customer instance in the constructor?
Same question with regard to Customer and CreditCard.
Sorry if I lack some understanding here. If someone could enlighten me, I sure would appreciate it.
Art

[Rufus BugleWeed]

I think you are understanding pretty well.
I don't think it implies an instance variable, just a reference. I would think an instance variable might deserve a hollow or a filled diamond. But even the experts disagree on this.
Like you question, one would think a Customer could find its orders or address.
Gennaldy Shapiro, a notable discusser here, made some very unflattering comments about the study guide.
It might be that you are expected to know what the Customer is to begin with. So "Select * from Order where Customer=xxx" finds the orders or the address in RDBMS think. With entity beans there will be finder methods.
[ February 11, 2003: Message edited by: Rufus BugleWeed ]

[Ted Bell]

Thanks for the reply. I was reading over Fowler's UML Distilled trying to understand this better. Oddly enough, he includes an example showing a Customer and an Order.
His first example has no arrow on either end, which I take to mean bidirectional (he says this can also be taken to mean "undecided").
In a following example (Figure 4-2) he adds an arrow on the Customer end (just like Cade's). He makes this change to exaplain navigability:

In an implementation diagram, this would indicate that Order contains a pointer to Customer, but Customer would not have a pointer to Order.

I'm wondering if those who have passed part II gave very much thought to navigability in their class diagrams.

[Yang Yu]

Art.
I was bit a confusing when I read the class diagram. My opinion is that navigability between customer and order and customer and address should be bidirectional. in addition, easy way to understand navigability is that if a -> b, it simply means that from a knows b but not vice verse. And in your comment, you said that there is an instance of b in class a, this is definitely correct.

[Roger Zacharias]

Hi,
I think the navigation from Address to Customer is the wrong way!
What do you think?
Roger

[ravi appala]

Hi
I am little bit confusing too with the architect experts class diagrams in various books to actual basics.
May be SCEA in the group clarify us. If A associates B, does A should hold the reference in class A implementation? We normally enhance Business Object diagram, actual implementation of business could be handled by some business handlers, there may not be direct reference in the class implementation, but as per business association is still enforced, what do we do in this situation, should we follow cade's or similar author class diagrams or go by basics?
I will give simple example, a busineess handler class enforce the business with creating order, creating it's items etc. but Order is associated to item per business diagram, implementation is done by business handler, actual order entity class does not have attribute to item entity class?
If you look at any author class diagrams, each single class some how associated with another. I did reverse engineering petstore, ther are many classes not even associated, some associated but not associated with remaining(order-orderdao, but order not with other classes)
Thanks,
ravi