Action Classes on Class Diagram?

[Chris Bicnal]

Howdy,

I'm starting to pull my class diagram together and have opted to use Struts2 as my MVC framework - question though, have folks who've used similar frameworks documented each Action class on their diagram?

I'm looking to wire my action classes through a business delegate to a session facade (via a service locator) so am concerned that things could get messy if I document each Action class.

What did folks do in this situation?

Similar for the sequence diagrams - at what point in the above chain would you begin?

Thanks,

Chris

[L Foster]

I'll keep this brief, because you may not like this 'solution'. I punted. In real life I would have definitely used Struts2, or JSF. Because I did not want to screw up the diagrams, I just implemented everything as bare JSPs and Servlets. I got 91% (146/160). I have no idea whether the bare JSPs counted against me or not.

A similar question has been asked before on this forum. There is probably a more direct way to reference this, but at least here is a link.
http://www.coderanch.com/t/425809/java-Architect-SCEA/certification/MVC-sequence-diagram

I just searched "ocmjea mvc framework uml" from a search engine, and landed there. HTH

[Chris Bicnal]

Interesting answer - thanks for that.

The more I'm learning about what other folks have done, the more I realise that it probably doesn't matter which way you turn with this stuff - as long as a) it meets requirements b) it would work and c) you can justify your decisions.

So, as long as everything makes sense and conveys the right message I think it will be fine either way!

[L Foster]

Another thing to keep in mind, is that extreme detail does not necessarily help. I have learned from various sources, that making the examiners go to extreme lengths looking at over-crowded diagrams will not earn more points. You don't want a diagram with too few details, that leaves them scratching their heads, and you don't want one with so many details that they throw up their hands in bewilderment. You can assume some things as just boxes covering a subsystem.

[Chris Bicnal]

Yes, I think an over comple class diagram is going to be the challenge with my solution.

The business model having the objects being traded broken down into precious/semi-precious with three or four types of gem linked to each is a recipe for a class explosion which I'm trying to figure out how best to handle.

If I were in real world I would store them all in one entity using various columns to identify whether it's a diamond or ruby or whatever and have one class to represent that table.

However, I'm not sure that's what's required here though given everyone seems to be saying that all objects in the business domain model must map to classes in the class diagram - any thoughts on that?

[L Foster]

Regarding class diagrams, my assignment PDF had an explicit diagram which they called "the business domain model". Everything I saw there, I slavishly included, even though I felt they might have been modeled with fewer classes. I later realized that there were significant differences in them, and it worked out OK. I wound up even adding more model classes to the hierarchy.

Now, I did have all these "similar things" inherit from a single class. That way, even though I had lots of these things, they could be treated polymorphically, and that meant fewer relationships being modeled. That means fewer lines running around, and that did help a bit with clutter.

I also did a little research on the domain of the assignment. It dealt with computer hardware and reverse auctions. I'd never heard of a reverse auction. After some research, I let some 'facts of life' about them influence the submission. I would humbly recommend you do the same.

I also tried to segment the object diagram roughly into tiers, like Web/Client, Business, and Resource. Anything that makes it easier to follow.

[K. Tsang]

When it comes to inheritance and such, too much classes may look bad, but having the necessary classes is important.

I had the same assignment as Foster and I knew exactly what he meant about creating polymorphically.

Anyway every approach has many solutions, rather than inheritance you may consider using Enum to represent the objects.

[Chris Bicnal]

My biggest bone of contention now is exactly how simple to make the class diagram.

When I say simple, I don't mean skimping out on the components from the Business Domain Model but how much other stuff should I include?

I started out with a Sruts2 implementation with JSPs through the Intercepting Filter to Action Classes which called into a Business Delegate which in turn used a Service Locator to obtain the reference to the Session Facade - the Session Facade then fronted the Entity objects. Whilst a mouthful, it was fairly comprehensible on the class diagram.....that was until I had other pieces of logic (which I'm implementing via Timer Beans) that should also be using the Service Locator and Session Facade, so it got really messy really quickly!

I'm now back a square one - KISS - following Cade's example which is actually very simple. Which has me second guessing again - is it too simple? My class diagram has 29 classes - of which 14 are from the Business Domain Model and the rest are my application.

What do we think? Too many? Not enough? About right? Time for alcohol....?

[K. Tsang]

Chris Bicnal wrote:
What do we think? Too many? Not enough? About right? Time for alcohol....?

Alcohol for sure

[L Foster]

@Chris,
At this point, I would turn your diagram over to someone else to have a look. See what kind of questions they ask. If they start to squint at something it may need more detail. If you have to answer one or two small questions (you can put those on as notes) then you probably have the right level of detail. But suggestion is: have someone else look.

Good Luck

[Chris Bicnal]

Thanks L - I had someone on the Ranch take a look and got great feedback.

If anyone else would like to offer their help then feel free to Purple Mooseage me and I'll be in touch!