Some questions about Cade and Roberts' case study

[Mark Cave]

Hi,

I have just read the case study from Cade & Roberts' book and it gave me a picture about how to approach the diagrams. However, I have some questions about the diagrams in the book if you can help me.

DOM and Class Diagram:
1. The relationship between Product and ProductCategories is not the same. In the DOM it's 1-N while in the Class Diagram it's M-N.
2. How the relationship between ProductCategoris and Manufacturer is maintained? It's kinda hidden in the Class Diagram behind the M-N relation between Product and ProductCategories.

Class Diagram:
1. Why is the association between Address and Customer is pointing to Customer and not the other way around?
Currently it isAddress ----> Customer
Should not it beCustomer ----> Address
Usually if you have two Java classes one for Customer and the other for Address, the Customer class has an instance variable of type Address. The Address class has information related to street, zip code and the like, simply it doesn't know about the Customer class. Moreover, Customer ----> Address is the approach used in the blueprints Adventure Builder Application.
2. Same thing for the association between CreditCard and Customer.

Component Diagrams:
1. What are IAccounting, IShipping, IPayment and the other two interfaces represent and used for?

Sequence Diagrams:
1. Should I use classes and objects in the real assignment or components as Cade and Roberts did in the case study?

[David Follow]

Originally posted by Mark Cave:

Class Diagram:
1. Why is the association between Address and Customer is pointing to Customer and not the other way around?
Currently it isAddress ----> Customer
Should not it beCustomer ----> Address
Usually if you have two Java classes one for Customer and the other for Address, the Customer class has an instance variable of type Address. The Address class has information related to street, zip code and the like, simply it doesn't know about the Customer class. Moreover, Customer ----> Address is the approach used in the blueprints Adventure Builder Application.
2. Same thing for the association between CreditCard and Customer.

I came across the same question. I don't know either why the association is the other way around from a "common sense" point of view. I would also expect Customer ---> Address, since a Customer HAS-A Address. What was the motication in the AdventureBuilder?

D.

[Giri Alwar]

I can try to answer these questions.

DOM and Class Diagram:
1. Your observation is correct. My take is that it is a typo in the class diagram and the relationship should be many to one from Product to ProductCategory. In my opionion, changing the multiplicity would be changing the requirements.
2. The class diagram notes mention that Manufacturer has been made an attribute of Product. This makes sense since manufacturer is not significant enough to be its own class. The key point is that this change preserves the many to one relationship between Product and Manufacturer in the BDM. Each product now has one manufacturer and the same manufacturer can appear in several products (including no products). I wish the class diagram clearly indicated the manufacturer attribute though.

Class Diagram:
1. I too am not quite clear why the arrow is from Address to Customer.
2. This one is a little less confusing (though still not entirely clear). I was thinking of a Credit Card as containing the number, exp. date and more importantly to our discussion the customer name. I was thinking of the Customer as containing just basic information that identify the customer (id and name). Then, given a CreditCard, we should be able to tell which Customer it belongs to. However, given a Customer, we cannot tell which CreditCard they have from the Customer object (this relationship might be stored somewhere else). Now, I would depict this a little differently but this is the closest I can think of to explain this.

Component Diagrams:
1. These as you have guessed are interfaces. They are used to show that the dependency is to a well-published interface to the sub-system as opposed to having to talk to classes in that system. It allows for low coupling to the subsystem.

Sequence Diagrams:
1. My advice would be to follow the Cade-Roberts approach. Your sequence diagram will be a combination of components and entities in your class diagram.

[Mark Cave]

Thanks David and Giri for your help.