aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Some questions about Cade and Roberts' case study Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Some questions about Cade and Roberts Watch "Some questions about Cade and Roberts New topic
Author

Some questions about Cade and Roberts' case study

Mark Cave
Ranch Hand

Joined: May 22, 2005
Posts: 92
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
Ranch Hand

Joined: Oct 16, 2001
Posts: 223
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.


SCJP, SCEA
Giri Alwar
Ranch Hand

Joined: May 27, 2005
Posts: 37
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.



SCEA<br />SCJD<br />SCJP
Mark Cave
Ranch Hand

Joined: May 22, 2005
Posts: 92
Thanks David and Giri for your help.
 
Don't get me started about those stupid light bulbs.
 
subject: Some questions about Cade and Roberts' case study