Class diagrams

[Pedro Filho]

Hi,

I'm designing my SCEA project and i've a doubt about the class diagrams.

I've in my system the entity classes and the service classes.

I decided to separate both class diagrams in two parts:

The first part shows the entity classes and their relationships.

The second part shows the service classes like SLSB, SFSB, Managed beans, DAOs, etc...

What do you guys think about it? Is it right?

In the service class diagrams i didn't include any entity classes.

I was taking a look at Cade's book and he designed only one class diagram where it contains the entities and the service classes that are responsible for "manage" the entity, for example where a SLSB creates or searches an entity class.

Would i lose marks designing my system this way? how do you guys have designed yours?

thank's in advance.

[Cameron Wallace McKenzie]

What do you mean when you say 'entities?' Is this SCEA5? Are you using JPA?

-Cameron McKenzie

[Pedro Filho]

Cameron Wallace McKenzie wrote:What do you mean when you say 'entities?' Is this SCEA5? Are you using JPA?

-Cameron McKenzie

sorry for the lack of information.

yes, i'm using JPA. It's a JPA entity and it's SCEA5.

[Pedro Filho]

for example:

The entity class diagram shows the relationship between a Product and a Category or between an Order and a Payment. The multiplicity between then.

The service class diagram shows the SLSB and the interactions with DAOs, Factories, Managed beans. For example: the Shipping Service (SLSB) accessing a DAO to get shipping details like price .. etc..

i've provided all public methods referenced in other diagrams in both class diagrams.

[Pedro Filho]

come'on guys,

what do you think about splitting then up? is it a good choise?

i let then all in one but it's not readable...

[Duc Vo]

Pedro,

It seems you are working on the same assignment as me. Anyway, I am putting them on the same diagram. It's easier to understand since it'll be obvious on the diagram which entities being used by which service classes. Just my 2 cents, if you can't present your design on a single diagram there, then you may have over-designed the system.

Hope it helps! G'luck,

[Janis Kazakovs]

Hello Pedro,

It depends. Depends, for example, on how big your diagram is or how you document your architecture. I don't think there is right or wrong approach, just keep in mind that it should be readable. You, probably, don't want a reader of your architecture to scroll top-down-left-right in order to read you diagram. If you think you diagram is getting too big and contains to many details, just split it. But, don't forget to properly document it.

I, personally, had several class diagrams.

Regards,
Janis

[Pedro Filho]

ok,

thank you guys for the answers.

I decided to separate the diagrams to keep it more readable but i noticed some flaws while doing this.

I didn't provide any entity class in the service class so it's not clear when a service class has a relationship (dependency) with an entity class.

In the entity class diagram I showed the relationship (multiplicity) between the entities and in the service class diagram I showed the dependencies between then, where a managed bean uses an SLSB, a SLSB uses a DAO, etc.... but not when a SLSB creates an entity for example.

If I put both together and if I try to maintain the relationships and dependencies among all the objects it will become a big mess.

Did you guys show all the relationships between the entities and put all the service classes "using" the entities???


I was thinking about to let the relationships between the entities only in the BDOM (which i changed a little from the original one) and in the class diagram i could show all the relationships (dependencies) between all the classes without worrying about multiplicity, navigability among entities.

what do you think? did i make it clear to you guys to understand what i'm saying?

[Janis Kazakovs]

Pedro,

If I think about your design in terms of layers, then I could have a presentation layer, where I would put managed beans; then service layer, where the session beans would go; the domain model with your entities would go to a business layer; and infrastructure/integration layer that would contain logic to interact with external system, like your DTOs that encapsulate data access logic. If you want to split you class diagram in several, you could, for example, display your presentation and service layer on one diagram, while domain model on another one.

Janis

[muhilan govin]

Hi All,

We can still use EJB 2.1 as a part of J2EE 1.4 spec. This contains Entity Beans. So even if we are trying for SCEA5 I can use Entity Beans.

Please correct me if I am wrong.

Thanks and Regards,
Muhilan

[P Das]

Probably, you can use SCEA < 5, only if it is a constraint (for example, an upgrading project); not in general. In other words, you need to be familiar with EntityBeans (part 1) but you may not apply them for a new development project (part 2).

What is the opinion of others.

[P Das]

Sorry, I mentioned SCEA < 5, which should be read as Java EE < 5

[muhilan govin]

Hi,

My assignment states that i can use J2EE 1.4(Dream Car). That is the reason i went for Entity Beans.

Regards,
Muhilan