> 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 ]