• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Could Mark Cade's Class Diagram be wrong?

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am studying Mark Cade's class diagram for Golf Equipment Store (page169).
Some of the association seems wrong to me, please help!!

1. Address --> Customer
I would think the arrow should point from customer to Addrss, since customer class should contain (knows about) address, not the other way around. Similarly, the credit card and Order's relationship to customer seems wrong too. (CreditCard * --->1 Customer)

2. Order ---LineItem
In the book, this is a bidirection association. But in real life, shouldn't it be unidirection? Order should be able to query about LineItem, LineItem should not be able to query Order?


Is it possible Mark Cade's class diagram is wrong or I misunderstand it completely?

Thank you for your help in advance!!
 
Ranch Hand
Posts: 686
Mac
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would say, when you work as an architect then there are always cases where, what you think may be different then what other thinks. It may be wrong from one architect's point of view and may be true from other's point of view.

The best thing to do while working in on a real software,you need to understand your clien't requirement and make necessary changes as per requirement it may be not accepted at a first glance by an outsider architect who doesn't know the requirement in detail but they are needed from application point of view.

I would suggest rather then digging too much for unidirectional-bidirectional, do what you feel correct. Because you are gonna justify you design in the essay exam.

As far as SCEA concern, I suggest to implement all the relationship as a bidirectional, untill unless you are very clear, about the unidirectional relationship among the classes.
[ September 05, 2005: Message edited by: Jignesh Patel ]
 
Jo Yan
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for answering my question!

I agree that each architect has their own way. I am just trying to understand from a pure UML point of view.

About your suggestion that all association be bidirectional by default, I remember reading before it is more complex to implement than unidirection association and therefore should be avoid as much as possible. Thoughts on that?
 
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jo Yan,

Please use the Search feature on the top of the page and look for: Cade address customer.
Mark Cave asked recently a very similar question at https://coderanch.com/t/153542/java-Architect-SCEA/certification/Some-questions-Cade-Roberts-case.

Another good search is: 169 Cade.

-- Dan
[ September 06, 2005: Message edited by: Dan Drillich ]
 
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
from an UML standpoint you are right . Customer will be composed of many smaller classes , including address , hence you can navigate from customer to address.

Stick to Unified Modeling Language Reference Manual , I use that very often at work.
 
Dan Drillich
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jo Yan

You asked:

About your suggestion that all association be bidirectional by default, I remember reading before it is more complex to implement than unidirection association and therefore should be avoid as much as possible. Thoughts on that?



Martin Fowler says about it in UML Distilled, page #42:


Implementing a bidirectional association in a programming language is often a little tricky because you have to be sure that both properties are kept synchronized.



I would also add that it's rarely needed, at least based on my experience of 20+ years of programming.

-- Dan
 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Friends

I have to solve these requirements:
three classes A, B and C, A needs to know B,C needs to know B and A, two options are possible:
A<---->B<----C, A has a direct association with B,C has a direct association with B and a derived association with A
A----->B<----C----->A, all associations are direct
I add that B has no significant behavior, i'm only only interested by some properties of this object.
Thanks for any comment
Akar
[ September 07, 2005: Message edited by: Akar Rafidj ]
 
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jignesh Patel:
I would say, when you work as an architect then there are always cases where, what you think may be different then what other thinks. It may be wrong from one architect's point of view and may be true from other's point of view.



That is a nonscientific view I will never accept. We discuss for finding the most appropriate solution and clearness - in this forum and in real architect's life. UML is imprecise enough.

An arrow is to show the direction of navigability.

Jo is right for 1.: it does not make sense to navigate from the customer's address to the customer because you will not have loaded the address before the customer.

Jo is right for 2 too for the analogeous reason.: you first will locate the order and then will navigate from the order to its LineItems. Therefore at least an arrow from Order to LineItem should be shown. And it is even the typical example for a directed composition, so I would prefere to also see a rombus there.

Ok, there could be any abnormal case where to navigate the other way round, but because abnormal, we should not consider it unless the class diagram designer had noted so - but he did not in the book (and this is not adjacent).

Thomas.
reply
    Bookmark Topic Watch Topic
  • New Topic