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?
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,
“Everything should be as simple as it is, but not simpler.” Albert Einstein
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 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?
Joined: Aug 13, 2009
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.
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.
Pranab Das, PMP, SCEA
Joined: Jun 30, 2008
Sorry, I mentioned SCEA < 5, which should be read as Java EE < 5
Joined: Jul 26, 2005
My assignment states that i can use J2EE 1.4(Dream Car). That is the reason i went for Entity Beans.