• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

UML Class Diagram

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I'm a beginner in Java and I'm very confused with this UML diagram.
Can someone please help me put Customer class into code.
Since the arrow points to Customer class, Order class should contain a reference of customer object?
How do sendOrder() and receiveOrder() methods work here when there's no instance of Order class in Customer class...
Please help me.

Thanks a lot,
Mat
uml_class_diagram.jpg
[Thumbnail for uml_class_diagram.jpg]
 
Rancher
Posts: 167
7
Mac OS X IntelliJ IDE
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think that this arrow shouldn't be there. You have multiplicities on both sides which mean that both classes "know" about each other: each Order is associated with exactly one Customer and a Customer can have many orders (don't know why there is n instead of 0..*, haven't seen this one before). I don't think there is enough detail in the class diagram itself to implement it with code.
 
Marshal
Posts: 69494
277
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1....n does occur. It means you can't have an order without a customer ordering it.
 
Adrian Grabowski
Rancher
Posts: 167
7
Mac OS X IntelliJ IDE
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:1....n does occur. It means you can't have an order without a customer ordering it.



There is 1 on the Customer side so I would understand it as exactly one Customer per order. n is on Order side so, according to my basic knowledge of UML, it means that we can have * (many) orders (including zero). If it was 1..* I would read it as "many orders but at least one".
 
Campbell Ritchie
Marshal
Posts: 69494
277
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have fortunately forgotten most of my UML, but I think it is conceivable that somebody becomes s a customer and doesn't buy anything. If you enter a shop, you become a customer. When you ask for a packet of flour and find they have sold out, you have zero purchases. You can implement both similarly, anyway.
 
Saloon Keeper
Posts: 12027
257
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Matryhard Kit wrote:Since the arrow points to Customer class, Order class should contain a reference of customer object?


Yes. An order is associated with a customer. The association can be implemented by a field in the Order class, but there are also other approaches.

How do sendOrder() and receiveOrder() methods work here when there's no instance of Order class in Customer class...


I agree that this is poor design. Those method should be called send() and receive() and they should be part of the Order class.

If you MUST implement the design as the UML diagram dictates, then the sendOrder() and receiveOrder() should take an Order as an argument, but it doesn't really make sense and it's also not clear what the intent of those methods is in the first place.

Do you have any additional info about all the methods shown in the diagram?
 
Stephan van Hulst
Saloon Keeper
Posts: 12027
257
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Adrian Grabowski wrote:I think that this arrow shouldn't be there. You have multiplicities on both sides which mean that both classes "know" about each other


I don't think that's right. Multiplicities are properties of an association, and associations can be implemented in a variety of ways. Multiplicities don't imply anything about what a class knows about the class they are associated with. A good counterexample to your argument are many-to-many relationships in relational databases: The association is implemented by a separate table, where the original two tables don't contain any knowledge about each other.

Whether a class knows about another class is implied by the description and direction of the association and the reason for the association. In this case the reason for the association is unclear because no clear responsibilities have been defined. Without further explanation, the UML diagram is lacking and we can't tell how the association should be implemented.
 
Saloon Keeper
Posts: 22126
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That 1..n simply indicates a one-to-many relationship. And "n" can be zero in a case where your cart is empty.

I think that this diagram is one that is only listing the public members of a class, so that the private collection of Order's is not explicitly visible. I'm fairly certain that, for example, the ArgoUML tool allows that option.

Of course, there's also nothing listed for creating an Order or adding one to the Customer's collection of Orders - unless "receiveOrder" is simply badly named. So that would mean that the diagram is incomplete.
 
Matryhard Kit
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot for the replies guys. I got this diagram from my tutor's presentation and I found it on the web: https://www.tutorialspoint.com/uml/uml_class_diagram.htm
I was trying hard to understand the diagram but it seems the diagram is incomplete and just a rough example of UML class diagram.
I'm moving on to learn more legit ones. Thanks.
 
Tim Holloway
Saloon Keeper
Posts: 22126
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A practical note here. UML was a "must-have" skill in my town several years back and employers were demanding the usual age-of-product+5 years experience in Rational Rose - which itself was horribly expensive.

A couple of issues came up, though. One was that when you used the reverse-engineering diagrammer on an existing complex application, what you generally got was a LOT of cubicle wallpaper (the abomination known as Open Floor Plans hadn't struck yet). There was no way to prioritize or emphasize the important flows and relationships over the minor supporting parts. Every shrub in the forest looked like another tree.

Another thing was -  like so many other fads -  it gained outsized importance. Reportedly one large shop here in town had a 2-year timeline for a major project, spent 18 months drawing UML actor diagrams, and then panicked when time began to run out. It sounded a lot like how Fred Brooks describer the OS/360 project in The Mythical Man-Month.

I'm not going to say that UML is useless. I keep a copy of ArgoUML handy and I'm especially fond of swim-lane diagrams myself. Just saying that UML is probably not going to be that big a part of one's professional life. At best, you might find yourself scribbling a few basic elements on the back of an envelope to help visualize the shape of a program being developed.

It's like flowcharts. Once an essential part of any major project, object-oriented programming has largely eliminated the need for fully mapping out the logic pictorially. Another tool that I used to love, incidentally, was IBM's HIPO diagrams (Hierarchy plus Input/Process/Output), They used it heavily in the System 360/370 era as illustrations in their OS program logic manuals. The "H" part of HIPO was an organization chart of the main and subsidiary modules. The IPO was a lot like a UML 3-column swimlane, but with different types of arrows to indicate control and data flow. Hierarchy diagrams don't do that much for OOP, and the same things that relegated flowcharts to secondary design aids made IPO diagrams fade away.

A diagramming technique that is still probably applicable to program logic (as opposed to overall archicture) is Nassi-Schneiderman or decision table diagrams. There's a GUI tool to develop them that's written in Java. At one time, in fact, people were hyped on the idea that you could eliminate programmers by having code generated directly from these charts, but like all the attempts to make coding obsolete, it wasn't sufficient to the task.
 
Adrian Grabowski
Rancher
Posts: 167
7
Mac OS X IntelliJ IDE
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:That 1..n simply indicates a one-to-many relationship. And "n" can be zero in a case where your cart is empty.



Just wanted to clarify one thing: when I say 1..*, 0..* or 0..5 I mean the multiplicity on one side of the relationship where dots indicate the range, not the line between two classes.
 
Campbell Ritchie
Marshal
Posts: 69494
277
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was using ... to mean the same thing.
 
I miss the old days when I would think up a sinister scheme for world domination and you would show a little emotional support. So just look at this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic