• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Class Diagram

 
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I have following queries on class diagram.

1. while designing classes, do we show only business classes in class diagram or can we show DB, VO, facade classes along and their association with business classes?

2. I wanted to know if my approach is correct. Take an example where I have a System configuration module which is used to configure the system by adding/updating/deleting configuration items.

In this scenario, my classes would be System Configuration and Configuration Items and System Configuration has Configuration items. I thought of defining Configuration Item as a ValueObject with Getter and setter methods and System Configuration would have a business methods to add ConfigurationItem, DeleteConfigurationItem, UpdateConfigurationItem, getConfigurationItems. In the System Configurtion class I am not thinking of holding ConfigurationItems collection as a paramter, as I would be returning that from getConfigurationItems method and ConfigurationItems are probably built in DB class and returned to Business class. I was thinking of sending ConfigurationItem as a method parameter to add/update/delete method. In this case, how will I represent the relationship between confgurationItem and SystemConfiguration. I see it as a composition relationship but I am not holding ConfigurationItems as a list in SystemConfiguration class.

I have my all classes like this. I have moved class attributes into valu objects and designed a seperate class for business methods. But by this I thinking I am not able to capture the correct relationship between business classes but I am capturing relationship between value objects.

I am not sure If my approach is correct or wrong. I would appreciate if anyone could take me to correct direction if I am going in wrong direction.

3. I am confused with association and dependency relationship. If one class is accessing a method on the other class then do we show that relationship using dependency?
I see association relationship as having other class instance as an attribute in a class. For example, if A and B are associated with each other and association is bi directional, then A would contain an instance of B as an attribute (i m not sure if it is class attribute or method atribute) and B would contain object of A as an attribute.

I would appreciate if anyone help me in differentiating between both.
4. I am thinking of having a 4 tier architecture.
1-tier- web component (jsp, struts)
2-tier - Facade classes that lookup for EJB
3-tier - EJB classes
4-tier - DB classes

Do we show all classes along with struts, facade, EJB, VO and DB in class diagram?.
 
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Saritha,

I see what you are saying. Usually, in this scenario I have the following components as core,

- Service Interface (in your case - SystemConfigurationService OR Session Bean's Remote Interface)
- Service Impl (in your case the class that implements storage of given DTO/VO to the Persistence Store OR EJB Entity Beans)
- Web tier stuff for querying and all (JSP+Struts)

The relationship between SystemConfigurator and the ConfigurationItem would be "uses" as it is not contained in the Configurator object.

I guess rest of the stuff you already understand.

Regards
Maulin
 
Maulin Vasavada
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
also..

Not only "Class diagram" would be suffice as you have to show following,
1. Static relations (class diagram)
2. Dynamic relations (communication between Web to EJB Tiers via Facade and all)...

I have put up two UML diagrams here,
1. End to end communication
- It describes sequence of how web tier queries EJB tier (actually the session/entity beans can be replaced by servlet/dao objects to fit J2SE)

2. Service implementation architecture
- It describes how a service is defined and implemented
- You can ignore the "connector" parts actually if you don't have third party using your services...
- Here, ServiceImpl can be J2EE or J2SE you know but I am just trying to model things in general in this diagram..


I am thinking that I can draw some standard diagrams I have with me with some more details and that might help many people. We don't have to "re-invent" even Diagrams

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

Originally posted by Saritha ventrapragada:
Hi,
I have following queries on class diagram.

1. while designing classes, do we show only business classes in class diagram or can we show DB, VO, facade classes along and their association with business classes?

Do we show all classes along with struts, facade, EJB, VO and DB in class diagram?.




You can get some hints using the BluePrints document:
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/sample-app/sample-app1.3.1.pdf

Here is what I see from the above document. Class diagrams can be presented in two types: "framework class diagram" (Fig. 17) and "structure class diagram" (Fig 20). Based on this, I would include Struts actions, session facades and DAOs in the first one and include all the VOs in the second one.

Hope that helps,
Nalla
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Hi,
I have following queries on class diagram.

1. while designing classes, do we show only business classes in class diagram or can we show DB, VO, facade classes along and their association with business classes?

Do we show all classes along with struts, facade, EJB, VO and DB in class diagram?.



To the level of detail required - focus on the audience and what you want to tell them. If you're talking to a senior developer who is familiar with all the Sun patterns, you might just put in the major businessy objects. If you have a new developer you might want to show all the details. If you produce a document for future generations of unknown abilities you might include both and let the reader match his skills to the diagrams.

One cool thing about a tool like Rose is that you can make a detailed model and then choose how much detail to put into various diagrams. Of course you can do the same thing with pencil & paper but it's more work to keep all your diagrams consistent.
 
Saritha Penumudi
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
Thank you all for responsding to my query.
Audience for my class diagram are beginners in Java. They are new to this technology.

I am more confused with dependency and Association relationship.

I would appreciate if you could provide me a info or explain me the difference and when to use them.

In my current scenario, I was using dependency relationship when Class A require to call a method on class B. And I am using association when I am using including class B as an attribute in class A.

I would appreciate if any one could clarify me this.

Thank you
Saritha
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm interested in dependencies for a couple reasons. This is probably not the UML definition:

A depends on B if ...
* B must be present to compile A
* B could change in a way to make A not work

Say I have a method parameter declared as type List. I have a dependency on the interface List. If Sun removed a method from a future version of List they'd break my code. Sun is pretty smart and I don't expect that, so I can say I have a dependency on a very stable interface. Somebody calls my method with an argument of type ArrayList. I have no dependency on ArrayList, don't need it around at compile time. In fact somebody could call me with a totally new List that they invented. I'd never know the difference.

A depends on interface C, B depends on interface C, but A does NOT depend on B.

Does that help you decide when to worry about dependencies enough to show them on diagrams?
 
Saritha Penumudi
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Stan James. Your explanation was helpful. When do you anticipate of using Association relationship between classes?
 
Here. Have a potato. I grew it in my armpit. And from my other armpit, this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic