aspose file tools*
The moose likes Java in General and the fly likes to create relationship amongst various classes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "to create relationship amongst various classes" Watch "to create relationship amongst various classes" New topic
Author

to create relationship amongst various classes

vaishnavi Mukundhan
Greenhorn

Joined: Apr 14, 2013
Posts: 16
my work is to actually find out classes and their relationship from a given case study.so I've already done the part of taking out classes.by extracting nouns and verbs from the sentence using a bnf grammar.So the nouns becomes the classes and the verbs the relationship.the problem i'm facing here is that i'm not able to associate the classes and appropriate relationship .
for ex
A library issues loan items to each customer. Each customer is known as a member and is issued a membership card that shows a unique member number.


in this I'm able to identify that library, customer,member,membership card,member number are the classes and issues,known,shows are the relationship.
but m not able to do the part which says customer --known--member ,library--issues--loan items, membership card--shows--member number.

how do i do this in java?any ideas? please do help
thank you
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Verbs are used for methods, not relationships.

Relationships would typicaly be IS-A (inheritance) or HAS-A (composition).

So, for example, the Library class might have an issue() method.
vaishnavi Mukundhan
Greenhorn

Joined: Apr 14, 2013
Posts: 16
Jeff Verdegan wrote:Verbs are used for methods, not relationships.

Relationships would typicaly be IS-A (inheritance) or HAS-A (composition).

So, for example, the Library class might have an issue() method.


ok so how do i relate the classes with it's methods ?
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5288
    
  10

If I'm not mistaken, these "relationships" you're talking about pertain to the lines connecting classes in a UML diagram, correct?


Junilu - [How to Ask Questions] [How to Answer Questions]
vaishnavi Mukundhan
Greenhorn

Joined: Apr 14, 2013
Posts: 16
Junilu Lacar wrote:If I'm not mistaken, these "relationships" you're talking about pertain to the lines connecting classes in a UML diagram, correct?


yup
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5288
    
  10

Well then you're going down the wrong path, IMO. For example, rather than Customer -- known -- Member, I would diagram this as [Customer (aka Member)]. That is, a Customer is also known as a Member -- they are different names for the same entity. Rather than Library -- issues -- Loan Item, I would diagram Member -- borrows -- Loan Item. Another facet of a UML class diagram is that it often shows cardinality, such as in Member -- borrows -- Loan Item, there is a many-to-many cardinality on either side because a Member can borrow multiple Loan Items and a Loan Item can be borrowed by multiple Members (over time). You could also have multiple copies of a Loan Item which can be borrowed by multiple Members at the same time.

The point I'm trying to make is that because a UML class diagram is an abstraction, there are some (and potentially many) things that get lost in the translation or are either implicit or borne out during discussions about the diagram. This lack of detail is intentional -- it is, after all, an abstraction. A UML diagram serves a purpose while code serves another purpose. What exactly is your purpose and what do want to achieve by making the translations you have described?
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5288
    
  10

An astute designer would note that there are alternatives to "Customer (aka Member)". This goes to my point about abstractions and details that need to be borne out in conversations. A UML class diagram is not the be-all and end-all of a design. It should spur conversations between people that help to further deepen their understanding of the system they are developing and using.
vaishnavi Mukundhan
Greenhorn

Joined: Apr 14, 2013
Posts: 16
Junilu Lacar wrote:An astute designer would note that there are alternatives to "Customer (aka Member)". This goes to my point about abstractions and details that need to be borne out in conversations. A UML class diagram is not the be-all and end-all of a design. It should spur conversations between people that help to further deepen their understanding of the system they are developing and using.


my purpose is just the code.I'm not doing the designing part. All i want to know is how to I correctly associate the nouns with the verbs.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5288
    
  10

vaishnavi Mukundhan wrote:my purpose is just the code.I'm not doing the designing part.

Code is the Design. When you code, you design. You should have an idea of the design before you code but as you write code, your idea gets refined and elaborated. As for associating nouns and verbs, it's the same thing: they are ideas that get refined and elaborated as you go.

"Member -- borrows -- Loan Items" is a skeleton of an idea. If a verb is a method, then where do you put the borrow method? Is it on the Member or on the LoanItem? What about the points about cardinality and the consequences of considering relationships over time (temporal)? How is that translated to code?

I guess what I'm trying to say is that your goal of associating nouns with verbs is an oversimplification of a complex process of idea elaboration and refinement. There isn't any one correct way because there are multiple interpretations that you can come out of it and all of them may seem correct on the surface. What you're doing should be just a means to an end, not an end itself.
vaishnavi Mukundhan
Greenhorn

Joined: Apr 14, 2013
Posts: 16
Junilu Lacar wrote:
vaishnavi Mukundhan wrote:my purpose is just the code.I'm not doing the designing part.

Code is the Design. When you code, you design. You should have an idea of the design before you code but as you write code, your idea gets refined and elaborated. As for associating nouns and verbs, it's the same thing: they are ideas that get refined and elaborated as you go.

"Member -- borrows -- Loan Items" is a skeleton of an idea. If a verb is a method, then where do you put the borrow method? Is it on the Member or on the LoanItem? What about the points about cardinality and the consequences of considering relationships over time (temporal)? How is that translated to code?

I guess what I'm trying to say is that your goal of associating nouns with verbs is an oversimplification of a complex process of idea elaboration and refinement. There isn't any one correct way because there are multiple interpretations that you can come out of it and all of them may seem correct on the surface. What you're doing should be just a means to an end, not an end itself.


Yeah .I just want to oversimplify it.Do you have any idea how to do it?
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5288
    
  10

vaishnavi Mukundhan wrote:Yeah .I just want to oversimplify it.Do you have any idea how to do it?

Yes, just keep doing what you're doing now.
vaishnavi Mukundhan
Greenhorn

Joined: Apr 14, 2013
Posts: 16
Junilu Lacar wrote:
vaishnavi Mukundhan wrote:Yeah .I just want to oversimplify it.Do you have any idea how to do it?

Yes, just keep doing what you're doing now.


thank you
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: to create relationship amongst various classes