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

Part II - Viable Action Plan ?

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Greetingz Everyone
I'd just like to get a feel for a couple of issues regarding part II that I'm slightly unclear on. Firstly, I just wanna say that I have limited UML experience but I have read a mixture of UML books that covers the intricasies of Class Diagrams, Component Diagrams and Sequence Diagrams so I now feel relatively comfortable with what must be submitted.
What I am asking is for comments to my approach in tackling this assignment and inparticular some outstanding issues with respect to UML :-

1) Based on the information supplied, I am planning on constructing the class diagram first. My intentions are to keep the diagram as simple as possible. I do not intend to introduce any J2EE components (EJB's, Servlets, JSP's etc classes) into the diagram as I feel this would cause unnecessary clutter. I believe these type of components would lend themselves to the component diagram.
My class diagram will be an extension of the BDM. I do not agree with the relationships of the BDM but I do not want to waste time with details that should have been cleared up via the business analyst. In reality, I would not second-guess business expectation or requirements. If things are unclear I would have walkthrough meetings and JAD sessions. Unfortunately, with this assignment - this is not possible. I will tackle this by stating this in my assumptions. With this in mind, I would like to know whether a class diagram MUST contain every class/object discuseed in the use cases ?
Is there a documented approach to constructing a class diagram ? i.e, must one construct it from use cases ? Or would you identify the classes and associations from a sequence diagram ?
How much *detail* is necessary to show on a class diagram ? It would appear to me that there would be a high level class diagram that just showed the top level classes (no J2EE component classes) and then a further detailed class diagram that showed attributes, methods, multiplicity. I have read that a class diagram is correct even if you just show the classes in their rectangles and draw the associations between the classes but Sun must have some idea as to the level of detail required.
Okay , I better leave it at that ...
TIA
Tanya.
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Is there a documented approach to constructing a class diagram ? i.e, must one construct it from use cases ? Or would you identify the classes and associations from a sequence diagram ?


The extention of Domain Object Model is usually called as design model. It is a good idea to come up with usecase flows first before you attempt to draw the design model. Although it is not required to be a part of your final submission, try describing the steps involved in realizing a particular usecase. This will eventually become your reference document for drawing sequence diagrams.
One of the things you should focus on is the transition of the domain object model into the design model. This not only involves mapping classes to implementation stereotypes, but also entails refactoring and applyling OOAD principles. If you do this in conjunction with describing the usecases, you will also able to flush out the attributes for each of your class. Once you have completed the usecase analysis, go back to your design model( that now has attribute definitions ) and try to identify generalizations, specializations, aggregates, composites etc. Ask yourself questions such as "what is common between these classes..?" or "is this type hierarchy sufficient enough to account for all the variations...?"
Once you are done with refactoring, try mapping your classes to J2EE components. ie,. data as entity bean, shared behavior as session bean etc. To avoid clutter, I suggest that you use stereotypes to begin with and later on add the J2EE interfaces to the diagram.


How much *detail* is necessary to show on a class diagram ? It would appear to me that there would be a high level class diagram that just showed the top level classes (no J2EE component classes) and then a further detailed class diagram that showed attributes, methods, multiplicity. I have read that a class diagram is correct even if you just show the classes in their rectangles and draw the associations between the classes but Sun must have some idea as to the level of detail required.


Since you are required to submit a component diagram along with the class diagram, I suggest that you model high level subsystems ie., JSPs, Persistence pacakges etc in the component diagram instead of cluttering the class diagram. You can simply use an actor in the sequence diagram to indicate the User Interface/UI Controller component. I am sure people have used different degrees of detail in each of the diagrams, so others may have different take on this issue...
Hope that helps...
 
Tanya Evans
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ajith - thanks for your response :-

>>It is a good idea to come up with usecase flows first before you attempt >>to draw the design model. Although it is not required to be a part of your >>final submission, try describing the steps involved in realizing a >>particular usecase. This will eventually become your reference document >>for drawing sequence diagrams.
I agree with your statement above but with reference to the assignment - I was under the impression that 4 Use Case flows have indeed been defined already via the business analyst who constructed the analysis so i'm unclear as to your meaning here.
Furthermore, I've also noticed that the assignment has asked for the delivery of a sequence diagram for all of the Use Cases supplied. Now I'm sure somewhere this question has been asked already so it should be easily answered :-
There are 7 Use Cases but only 4 detailed use case descriptions, is it fair to say that only 4 sequence diagrams are supplied and constructed for the 4 use cases (and state this on your assumptions page) or is the assignment description misleading in asking you to fill out and specify the use-case flows of the other three and consequently construct 7 sequence diagrams ?
One last point, I've noticed that most posts here discuss the submission of a Sequence Diagram as opposed to a Collaboration diagram. Is there any major reason why everyone is going down this route when Sun gives us the option of either ? Being new to UML, is one more easily constructed then the other ?
Thanks alot.
Tanya.
 
The human mind is a dangerous plaything. This tiny ad is pretty safe:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic