Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

class diagram objects vs. sequence diagram objects

 
guy katz
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi;
many people stated that their class diagram contains all the objects in the sequence diagrams (25-30 classes). looking at cades approach i noticed his class diagram show less objects (within a given scenario) then his sequence diagrams. he ommited from the class diagram the web container objects & value objects, and data access objects.
did anyone take this aproach (small class diagram which is the original BDM + some modifications/extensions and bigger sequence diagrams)? i would also like to hear the opinion of people that took this approach and passed.
thanks.
 
Darryl A. J. Staflund
Ranch Hand
Posts: 314
2
Android Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guy,
I'm encountering the opposite problem and am re-evaluating how I am doing the sequence diagrams. My problem is that I have a LOT of classes -- many of which are introduced into the system because of design pattern choices and the number of JSP pages, etc.
For example, suppose in a given design you are going to use filters, a command pattern, a value object assembler, session facades and delegates, service locators, DAO's, etc. Even if you avoid depicting local/remote/localhome/home interfaces, lifecycle calls, etc. you still have a heck of a lot of classes. So I am sitting down and reevaluating what it is that I hope to display in my sequence diagrams that will strike a balanace between conveying business flow and showing architectural composition and strategy in my design.
How are you dealing with this?
Darryl
 
Bill Morrison
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gentlemen,
I have been reading several sources on depicting J2EE components and systems in UML. At this time, there seems to be several approaches with little formality beyond that which UML itself provides. Find "UML Profile for EJB" for a draft spec from Rational. Also, "UML J2EE" on Amazon yields a couple of good books.
To the point though, UML provides the notion of stereotypes that allows us to use shorthand notation in modeling systems that are based on defined types.
The question might be: What are the stereotypes that readily recognized or otherwise needed to be defined?
Regards,
Bill
 
guy katz
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi;
darryl; i must say we share the exact same problem.
i think i decided with myself not to include VOs, DTO's, filters,business delegators etc in the class diagram. i will include them in the sequence diagram though.
My decision is not based on any insightfull thoughts but is more of an extension to the approach cade had when designing his diagrams.
what do you think?
 
Darryl A. J. Staflund
Ranch Hand
Posts: 314
2
Android Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
> i think i decided with myself not to include
> VOs, DTO's, filters,business delegators etc in
> the class diagram. i will include them in the
> sequence diagram though.
We have different tendencies here, Guy. I'd like to leave the above classes out of the sequence diagrams and include them in my class diagrams -- on the assumption that I want my use cases to depict business flow between objects outlined in the use cases, whereas I want my class design to indicate to the development team what design patterns should be adopted, etc.
But I like the idea of including pattern-related classes in the sequence diagrams because I can visually see what is going on and can also identify larger behavioural patterns that I can factor out into separate sequence diagrams. What concerns me about this approach, however, is that a lot of the sequence diagrams will be spent depicting common actions such as (i) dispatching requests from controller to form; (ii) requesting the helper classes to return command objects; (iii) locating a resource using a service locator; (iv) issuing commands between delegate and session facade; and worst of all (v) creating value objects. This is a lot of (sometimes) complex and repetitive detail that the developer might find useful but the business analyst, etc. might not.
** sighs ** I don't know. Allen and Bambara in their new book on SCEA give the following definition of a use case: "[a] sequence diagram describes how groups of objects collaborate in some behaviour over time. It records the behaviour of a single use case. It displays objects and the messages passed among these objects in the use case." (pp. 92-3). This is how I tend to view sequence diagrams -- as depicting the business flow of a use case. When I look at it this way, design patterns get in the way of what the sequence diagram is trying to achieve. Yet Cade defines use cases somewhat differently in his book, i.e. they are "..interaction diagrams that emphasize the time-ordering of messages." (p. 46) Cade's emphasis in this passage that sequence diagrams depict the dynamic parts of a system. The question remains open whether our audience is the developers or the business community.
So, for me, the question on how I should approach the drawing of my use cases depends on who my intended audience is or what I am trying to communicate with them. Normally, I'd address my sequence diagrams primarily to the business community since, if the business community is happy with them, then developers and testers, etc. can be assured that anything they build off of them will reflect true business needs. The class diagram I would address to the developer community.
But that is real life. My audience here is Sun / Prometric! I wonder what they are looking for. Maybe all I have to do is explain who my target audiences are as part of my assumptions :-)
I like that idea.
Darryl
[ April 27, 2003: Message edited by: Darryl A. J. Staflund ]
 
Darryl A. J. Staflund
Ranch Hand
Posts: 314
2
Android Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bill,
Thanks for your response. I am not sure how using stereotypes to extend my metamodel will help me deal with class explosion in my sequence diagrams. It is true that I can use sterotyped classes to eliminate interfaces like those that would appear with session bean, entity beans, message driven beans, etc. But I am not sure how I would use stereotypes to minimize the number of classes introduced into a system due to the adoption of certain design patterns like delegate/facade interaction, class/locator interaction, creation and transferance of value objects, etc. Any examples on how I can use stereotypes to achieve this? If there is, this would save a LOT of work!!
Having said this, Grady and Booch do introduce some nice UML objects that can simplify the presentation of design patterns, i.e. a construct named parameterized collaborations. However, I've never been able to find a UML IDE that makes use of them and they're more common used in package diagrams. I don't think for the sake of this assignment we could use them in sequence or deployment diagrams, but we 'may' be able to use them in class diagrams.
Suggestions?
Darryl
 
Darryl A. J. Staflund
Ranch Hand
Posts: 314
2
Android Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, I think the strategy I am going to adopt is to create a separate sequence diagram for each Command executed in the course of a use case and then link them all together to create an ordered flow in my HTML diagrams. Although I'll have a lot more diagrams to create, each of them will depict the logic involved a single round-trip from customer to server and back and the size of each of them will be manageable. And, more important, it will let me depict design class detail for the developer since the diagram will be a lot smaller.
Yeah, I like that idea!
Darryl
[ April 27, 2003: Message edited by: Darryl A. J. Staflund ]
 
Eduard Manas
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there,
Regarding to the intial question, my approach has been to split the class and component diagrams in smaller and more manageable diagrams; and I have added most of the VO objects I have used. I know they say to only submit ONE class/component diagram, but I am sorry, I don't agree with them.
Any class diagram with 25-30 classes is going to be far too big and cluttered, not to mention a hell to maintain and update in the future, or attempting to print it out in any standard piece of paper. On the top of that, if you have got developers only working in one use case, you make them swallow a huge class diagram that contains a lot of classes out of context for them.
In the same way I also think that only one sequence diagram for each use case will make far too big diagrams (same reasoning). I have also split them on (more or less) one sequence diagram for user interaction. I haven't added VO on them, although I provide comments saying what VO should be used.
I have reasoned my approach (and it's too late to change it anyway), so if they like it fine, and if not... then I'll have to buy Cade's book to see how it has to be done for the assigment, but my respect for SCEA will have drop considerably.
Just the future will tell...
Eduard
 
Owen Leung
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My class diagram has 25 to 30 classes (the objects in the class diagram does not necessary to match with the objects in the sequence diagram). It fits on one page (portrait) and it's pretty clear. I think it depends on how you organize your classes to show them on the class diagram.
[ May 01, 2003: Message edited by: Owen Leung ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic