Cade's Class Example use of Association

[Peter Bergoff]

Hi everyone,

This is a question I posted a while ago and thought I'd try again to see if some REALLY smart person could give me a good answer. : )

While reviewing the class diagram in Cade's SCEA Study Guide in the case study (pg. 169):

Regarding the association between the classes Customer and CreditCard - why is the navigation arrow pointing towards Customer? Shouldn't the arrow point the other way (i.e. Customer has a reference to CreditCard). Why would the CreditCard class need a reference to Customer?

And also the same question regarding why the Order class has a navigation arrow pointing to Customer.

I'm not able to find really clear definitions and examples of how to use the association�s navigation arrow so if you know of any that would clear this up for me I would be very greatful.

Thanks.

[Sanz Vai]

I also thought about it. But if you think in real life situation, you will find that a credit card and customer are really independent objects. A customer knows its credit card, by, say credit card number. A credit card knows who this card belongs to by, say social security number. So given a customer, we can find all credit cards that belong to him and given a credit card, we can find to whom it belongs to. So we could just get rid of the arrow.

[Seshagiri Rao Ananthaneni]

We shouldn't keep referrence to order in customer. If you do that customer will become order. If there is no order class then we can do that!!!. same the case for credit card
one customer can have multiple orders not the other way round. so navigation always points to customer

[Ramon Gill]

I agree with Sanz (remove navigation arrow). Both Larman and Fowler say not to use navigation in conceptual class diagrams.

Ray

[Seshagiri Rao Ananthaneni]

It is upto you whether you show navigation or not. if you show navigation itself show you dependancy. if there are many dependancies on customer we can't reuse it

[Sanz Vai]

It depends on how you implement your relationship. True, a Customer knows about Order, and the Order may or may not know about Customer. But for Customer and CreditCard, in real life situation, they both know about each other. If you have a CrediCard, you should always be able to find to whom it belongs to, say through Soc. Sec number etc.

[Seshagiri Rao Ananthaneni]

Sanz Vai, I am not getting you. just finished my part1 may be i am wrong. My understanding with navigation is Order class should have the responsibility to say who is its customer and customer don't know about his orders(according to navigation in cade's diagram). your statement contradicting this. please explain.

In my understanding creditcard class should be helper class. if it is persistant class what is the need to store the details(reusability? then what about security?). I am asking this because it is showing one to many relationship. we only give one number at the time of purchase. right?

And also the navigation in cades book between lineitem and product is bidirection(or notdecided?). how should it be. order line should contain product and has the responsibility to tell what are products in order line. how can product know about order line

someone please help me out
[ July 09, 2004: Message edited by: Seshagiri Rao Ananthaneni ]

[Srinivas Bitla]

Hi,

One way of finding a solution to this is to think how can we model these classes in a relational database. If we have Customer and Creditcard, then it is likely that we will have two tables Customer and Creditcard, because these are two entities.

Then solution to this problem resides in how do we represent a relationship between these two tables. Because a Creditcard belongs to only one Customer, it is easier to represent this relation as a foreign key from Creditcard to Customer. It is very difficult to represent this relation as a foerign key from Customer to Creditcard, because we need to have an arrey of CreditcardIds (or a similer mechanism) in Customer table as a foreign key refering to Creditcard table.

With this database design, given a CustomerId we can find his all Creditcards and given a CreditcardId we can find the Customer to whome Creditcard belongs to.

The database design might have driven the authors to have a relationship from Creditcard to Customer. Same applies to Order and Customer.

What are your thoughts?

Thanks,
Srinivas.

[Seshagiri Rao Ananthaneni]

Thank you srinivas. I think even in class design, it should be the way. my question on the credit card is why should it be persistant risking the customer. is it a good design consideration?
[ July 10, 2004: Message edited by: Seshagiri Rao Ananthaneni ]

[Peter Bergoff]

Hi Srinivas,

Your foreign key idea is interesting. A quick glance at the Cade class diagram it looks like it may hold up. Is there any good documentation to back up this thought?

Many thanks,

Jeff

[shay Aluko]

Originally posted by PETER BERGOFF:
Hi everyone,

This is a question I posted a while ago and thought I'd try again to see if some REALLY smart person could give me a good answer. : )

While reviewing the class diagram in Cade's SCEA Study Guide in the case study (pg. 169):

Regarding the association between the classes Customer and CreditCard - why is the navigation arrow pointing towards Customer? Shouldn't the arrow point the other way (i.e. Customer has a reference to CreditCard). Why would the CreditCard class need a reference to Customer?

And also the same question regarding why the Order class has a navigation arrow pointing to Customer.

I'm not able to find really clear definitions and examples of how to use the association�s navigation arrow so if you know of any that would clear this up for me I would be very greatful.

Thanks.

I believe we are confusing two concepts here, navigability and multiplicity.
I this case multiple credit cards and participate in a relationship with a customer and also a credit card can indeed have two owners.(e.g a man and his wife). I don't agree with Cade's diagram in this case because i believe the association ia bidirectional. A credit card know its owner(s) and the owner knows creditcard he/she has.so no arrows. Bear in mind Cade's diagram is really his opinion on how the relationship should be depicted. We are allowed to disagree...

[Srinivas Bitla]

Hi Peter Bergoff,

I do not have any documentation to support my thought, but given that scenario this is how I would design.

Thanks,
Srinivas.

[Srinivas Bitla]

Hi Seshagiri Rao,

If Creditcard is not persistent then how do you want to design it? By saying "risking the customer", do you mean that there are chances of Creditcard No. being compromised? If that is your concern then all customer passwords are also persistent in the database. These passwords are more sensitive than Creditcard No. Such sensitive information will be encrypted and then stored in a persistent store.

Please comment.

Thanks,
Srinivas.

[Seshagiri Rao Ananthaneni]

thanks srinivas. my question remains same. we will definitely encrypt password and credit cards.
what will one do if password is compromised(in shopping cart) ?. he will see your records and may try to make purchase on his name but he can't make it becuase he doesn't know your credit card details. If credit card details are stored in database we may reuse it and will show it on web interface and we are allowing a person to purchase on another persons credit card and allowing him to know customer credit card number.
i think we don't have to store credit card in database. why should we?. we will take it from web and pass it to credit card processing system through secure protocol.can't we?

[Srinivas Bitla]

Hi Seshagiri Rao,

Your statements are very conflicting.

You are saying that by storing Creditcard No. in the database there are chances of Creditcard No. being compromised. But we store passwords also in the database which are more sensitive than Creditcard No. If you do not want to store Creditcard No. in the database then you should not store passwords also in the database because when Creditcard No. can be compomised when stored in the database then passwords can also be compromised. So if you do not persist passwords then you need to employ a highly secured system that might use digital certificates for each customer to authenticate himself to the server, which is highly difficult. If you are a security expert then you agree that even these digital certificates are not 100% secure.

I also did not understand whome are you refering to by saying "he" and "your" in the statement "he will see your records and may try to make purchase on his name but he can't make it becuase he doesn't know your credit card details."? I guess "your" might be refereing to the customer but who is "he" refering to? If "he" is refering to one who has stolen the customer's password, then "he" can infact place an order with customer's Creditcard No. If the customer's password is compromised then it happened because of customer's mistake and not because of system's mistake. Customers who use internet are aware that passwords are more sensitive and should be secured.

And regarding taking the Credicard No. online, without persisting in the database, yes you can do so. We are persisting Creditcard No. only to improve the Customer's shopping experience by not entering his Credicard No. everytime he shops and also to avoid human errors that might occur while entering the credicard no. in the browser.

Thanks,
Srinivas.

[Seshagiri Rao Ananthaneni]

Sorry for troubling you.one last message. i am giving these messages just to know experienced people thoughts before i start designing. yes your interpretation is correct for "he" and "your". sorry for using those. Password will also be compromised if hacker got access to database somehow and replace encrypted password with something he knows.don't say that it decrypt differrently, suppose hacker replaces with another encrypted password hacker knows.
May be my messages are not clear enough, i will take care before i post from now. yes, password is very critical in some systems. credit card number is critical than that in shopping cart(in my view). i explained reason for that in my previous message. can hacker do any thing other than that?
[ July 11, 2004: Message edited by: Seshagiri Rao Ananthaneni ]

[Srinivas Bitla]

Hi Seshagiri Rao,

Your main concern as I understood from your postings is that, why should we give a hacker a chance to hack the system or databse.

If an architect takes a back step because the system can be compromised by the hackers then no system exists, because nothing is 100% secure. As an architect you can only garuntee that the system is 99.99% secure at the best.

A hacker can do anything if the system is not secure enough. A hacker can steal passwords, Credicard No.s or other sensitive information.

Can you tell me how a Creditcard No. is more critical than password in shopping cart? According to me, If the Creditcard No. alone is compromised then the hacker can use only that Creditcard No. to place orders. But if the password is compromised then the hacker can use all Creditcard No.s of the customer, whose password is compromised, to place orders and can also access other sensitive information.

Give your thinking a broder scope.

Thanks and Regards,
Srinivas.

[Seshagiri Rao Ananthaneni]

Thanks for your responses.I agree no system is 100% secure. I think the problem here is the way we are looking at the problem. I feel that creditcard details shouldn't be stored in database. If we store credit card details in database securing password is very important. hope you understand me.

[Srinivas Bitla]

Hi Seshagiri Rao,

I agree with your statement "If we store credit card details in database securing password is very important." Yes, in such a case we have to employ a highly secure architecture.

But if the business requirements demand the storage of Creditcard No.s, then I do not hesitate to persist them in a database and provide a secure architecture.

Thanks,
Srinivas.

[Seshagiri Rao Ananthaneni]

Hi Peter Bergoff,
i think your post took a new turn. have you understand the navigation or do we need to continue..
Rao

[Peter Bergoff]

Hey Seshagiri,

I'm still completely clueless as to navigation. Why is this concept apparently so subjective???!!!

[Seshagiri Rao Ananthaneni]

I will try to clear you but not sure how much it helps you. If you take the example in cade's book, all the navigation arrows pointing towards customer. that means customer don't know about other classes around it. this type of design is very helpful if you want to reuse customer(lightweight, so flexible). If you want customer to know about every class then customer becomes heavy. If you like to design in such way that customer knows about every object or some objects around it you can point the other way.
ranchers, you are allowed to differ or correct
[ July 12, 2004: Message edited by: Seshagiri Rao Ananthaneni ]

[Tomi Tuomainen]

Cade tells us... "diagram just shows the basic classes that will be used in the system to provide some structure and business rules". I think this means that the diagram is showing concepts of the system, but we are not interested about technology (for example if the database is relational or object oriented). So if we don't give a damn about database and just think about concepts, we could...

1) Add navigation arrow pointing from customer to order. This means that a customer holds references to its orders (in design level for example an array).

.. or..

2) Add navigation arrow pointing from order to customer. This means that an order holds a reference to its customer (a single reference attribute).

I don't know how to justify that one or the other is definitely right. I think that the problem here is, how much technological details do we want to expose to guide our designers? Cade seems to think that class diagram "knows" about session beans but nothing else about final technology (not even persistence of objects)