• 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:
  • Tim Cooke
  • Campbell Ritchie
  • paul wheaton
  • Ron McLeod
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:

The tricky stuff of the class diagram in Mark Cade's case study

 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Everyone,

When you look at the class diagram of the case study in the Mark Cade's book, You can't see which object manage the shopping cart and how the relation should be between those session beans. Also there is no relation with sub systems and third party systems. I don't agree that such class diagram would pass the certification in real world. But the fact is once we add those detail information with more classes and relation lines, the diagram would be more complicated, clutter and messy.

Any ideas about this?

Thanks.
 
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Humphrey Sheil (who authored the Big Smokes assignment) recommends against "Fragmenting UML diagrams according to some arbitrary scheme" (see page 20).

However, if you're diagrams are becoming overly complex and/or cluttered perhaps it's time to refactor them. If you ensure each diagram has a single well defined purpose, and you're consistent across all diagrams, you can't go far wrong (that's my opinion).
 
mimi mang
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for your share. I also read his chapter 9 of the new book to be published. Similar to the book of Mark, they really do the overall architecture without detail design. But I feel the assignment require you do kind of detail design because of the requirement of methods in sequence diagram need be in class diagram as well. For this requirement, I am still struggling of how to tradeoff it. Before I do this assignment, I feel it's a piece of cake. but when I am working on it, there are tons of things you need consider...... As a result, they will be complicated and clutter in the diagrams. Just because of this single requirement of methods need to be on class diagram, I am totally screwed up.

But Mark's sequence diagram is based on components other than classes. This makes sense from high level designing perspective. When you see Humphrey's chapter 9, his sequence diagram has no those DAOs which were shown on component diagram. The interesting thing is there is a JPA Entity Manager object on the sequence diagram other than DAO's. What if I do as his example? The most hard part of the assignment for me is not sure what level of detail or abstraction I should provide. But from my opinion, I think both examples in the 2 books are fine for architecture level design although it's not a complete solution of the business problem.

Any thoughts for share are appreciated.
 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I had no chance to look at new scea book, because of stupid policies of safarionlines has against my country (it's considered as country with high risk of card fraud ), but what regarding first SCEA book - level of detail provided there seems to me very reasonable, think we should provide something similar, maybe just little bit more fine grained (as with methods in class diagram). Components used in sequence diagram, because they correspond to classes there, there are no abstraction of family of components there. And such approach is also valid, although is little bit old-fashioned.

My main advise - don't panic, everything will be in place after you will do some work.
 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

mimi mang wrote:Thank you for your share. I also read his chapter 9 of the new book to be published. Similar to the book of Mark, they really do the overall architecture without detail design. But I feel the assignment require you do kind of detail design because of the requirement of methods in sequence diagram need be in class diagram as well. For this requirement, I am still struggling of how to tradeoff it. Before I do this assignment, I feel it's a piece of cake. but when I am working on it, there are tons of things you need consider...... As a result, they will be complicated and clutter in the diagrams. Just because of this single requirement of methods need to be on class diagram, I am totally screwed up.

But Mark's sequence diagram is based on components other than classes. This makes sense from high level designing perspective. When you see Humphrey's chapter 9, his sequence diagram has no those DAOs which were shown on component diagram. The interesting thing is there is a JPA Entity Manager object on the sequence diagram other than DAO's. What if I do as his example? The most hard part of the assignment for me is not sure what level of detail or abstraction I should provide. But from my opinion, I think both examples in the 2 books are fine for architecture level design although it's not a complete solution of the business problem.

Any thoughts for share are appreciated.



I agree with you that in the book of Cade, the solution is rather minimalistic. I'm confused about the JSP pages present in the class diagram.
I think that the requirement for methods used in th sequence diagrams to be present in the class diagram, doesn't concern the presentation layer. I want to use JSF framework for my presentation and normally I would add a managed bean in the sequence diagram, but not in the class diagram -otherwise my class diagram will become huge and too detailed while no added value for the diagram.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic