BDM Classes

[Giju George]

I have read in many topics that the class diagram should be more or less technology independent. The BDM provided in the assignment has got 7 elements. So do u think I can use the existing 7 elements as classes (with the same NAME) , and then extending some of the elements like customer etc.

[Ajai]

Yes ,even I have read all this in the forums.
How about UI classes ..in CT Arington book this is done.Do you think we have to add those also or just classes in the business tier only.

But that makes class diagram part quite easy ..In contradiction some ppl have failed coz of not so good class diagrams.

[Duren Lee]

1) U would carefully go through all the content of the assignment, find more entities except 7 BDM. or
2) finding more entites through seq. diag.

duren

[Giju George]

Thanx guys for the replies.
One of the old thread that I read, https://coderanch.com/t/152157/java-Architect-SCEA/certification/Part-should-class-diagram-reflect

And Ajith mentions here about including Session Beans in class diagram. That can be one reason why cade has also got session beans in his class diagram. Ajai, I don't really want to include UI classes there, because that's going to clutter the diagram.

[chao cai]

Did someone think the cart class will be included the class diagram? Is there anybody pass the exam without draw the cart class in the class diagram?

[Jim Janssens]

Originally posted by chao cai:
Did someone think the cart class will be included the class diagram? Is there anybody pass the exam without draw the cart class in the class diagram?

My view on a class diagram is that it should give a broader view of the BDM. I start from the idea that you should be able to draw the required sequence diagrams (for about 70%) with the classes on your class diagram. So that means that you will create 30% of custom classes for the sequences which are not displayed on the class diagram (UI components for example).

About the SSB's and all; I think that if you have a class that acts as a service (its a facade doing some delegation) then you can just leave of the SSB stereotype if you want to make your diagram technology independed. If you want to make it technology depended, you add the stereotype. There is nothing more to it I guess.

Things I would leave of a high level class diagram would certainly be implementation specific elements. Factories, TO's etc. Why ?

- They clutter the diagram
- They do not add any value at this level. Who cares that your service uses a factory to lookup a certain class it uses ? Thats a low level implementation decision. At this point it is intersting to know that class A uses class B.

Anyway, thats what I think of it, could be wrong ofcourse

[Jim Janssens]

Originally posted by Koen Serneels:


My view on a class diagram is that it should give a broader view of the BDM. I start from the idea that you should be able to draw the required sequence diagrams (for about 70%) with the classes on your class diagram. So that means that you will create 30% of custom classes for the sequences which are not displayed on the class diagram (UI components for example).

About the SSB's and all; I think that if you have a class that acts as a service (its a facade doing some delegation) then you can just leave of the SSB stereotype if you want to make your diagram technology independed. If you want to make it technology depended, you add the stereotype. There is nothing more to it I guess.

Things I would leave of a high level class diagram would certainly be implementation specific elements. Factories, TO's etc. Why ?

- They clutter the diagram
- They do not add any value at this level. Who cares that your service uses a factory to lookup a certain class it uses ? Thats a low level implementation decision. At this point it is intersting to know that class A uses class B.

Anyway, thats what I think of it, could be wrong ofcourse

Edit:

Oh, and why I would not put any of those UI components on the class diagram, would be that I find it to generic. As far as I'm concerned, the class diagram tells me something on how the business problem is addressed on a pre defined and standarized way (UML). The UI is not the business problem , it just a framework that you use to display the output of the business process.

I do agree that a class diagram is usefull for the UI part, but not at this level. This diagram should be created on implementation level.