Win a copy of Getting started with Java on the Raspberry Pi this week in the Raspberry Pi forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Tim Cooke
  • Jeanne Boyarsky
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Liutauras Vilda
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Piet Souris

Some questions about Cade and Roberts' case study

 
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks David and Giri for your help.
 
Listen. That's my theme music. That's how I know I'm a super hero. That, and this tiny ad told me:
Low Tech Laboratory
https://www.kickstarter.com/projects/paulwheaton/low-tech-0
reply
    Bookmark Topic Watch Topic
  • New Topic