In Cade's class diagram (pg 169), the relationship between the entity classes is depicted using association (solid arrow). But why not aggregration or composition relationship?
I'm quite confused with the relationship between ShoppingCart and Product. It seems to me that ShoppingCart references to a list of the products purchased by a customer. Why the relationship is dependency and not aggregration/association?
Joyce, Aggregation and Composition are both forms of Association. Cade may have made a decision to leave these decisions till later in the design. I see your point though, as Order/LineItem is a prime case for composition. I think its down to individuals as to what they show.
In my view, the relationship between ShoppingCart and Product shows that the ShoppingCart refers to Product to get information (i.e. price, description). The fact that a shopping cart will contain a list of items/products is not reflected in the diagram. Again, Cade may think that this is a decision later in design (i.e. to decide what a shoppingCart consists of).
But in figure 8-10, the ShoppingCart has a method addProduct(). It gives me the impression the ShoppingCart is holding a list products.
So in a class diagram, we can use either a general relationship (association) or a detailed relationship (aggregation/composition) between entity classes depending on the preference of individual or level of details.
Joyce, After having a look at 8-10 I see the confusion.
Could it be that ShoppingCart has a collection of Products/Items (i.e. referred by an attribute), and Cade has decided not to show attributes?
It seems that ShoppingCart needs to refer to a Product to get info like price, but also needs to contain a collection of items (with some Product data)that will eventually become LineItems in an Order.
ShoppingCart should at least hold a collection of productId, just like the one in PetStore's cart component. I wonder having the productId(s) in the ShoppingCart is considered as association or dependency.
Tomi, I'm thinking of shared aggregration instead of composite aggregation.
Ok, I think it's possible to be dependency if ShoppingCart is holding the productId only. ShoppingCart may have a method calls showDetails. This showDetails will return the detail info of all the products by using the productId(s) to retrieve info from the entities. [ July 22, 2004: Message edited by: Joyce Lee ]
Btw, the SmartTicket 2.0 sample code (Sun's blueprint) contains some UML diagrams.
A snippet of SmartTicketFacadeBean
Ticketing EJB is a stateful bean. The relationship between SmartTicketFacadeBean and TicketingBean shown in the uml diagram is dependency instead of association. I wonder whether the dependency is due to the fact that SmartTicketBean does not have direct reference to the TicketingBean. If that's the case, all the relationships between session beans will be dependency. What do you think?
[ July 22, 2004: Message edited by: Joyce Lee ]
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop