Joachim Heidenreich wrote:So in the 2. option, if youre not going to use SFSB, you're going to put the updated PurchaseRequest object into the request scope every time? I find that rather cumbersome because you will have to store the Purchase request in some hidden fields or request parameters in your JSPs in every call otherwise your data will be lost.
Why not store them in a HttpSession? You wont even need to have the method addItem return an updated PurchaseRequest becuase you would be using "call by reference."
Joachim Heidenreich wrote:Both seem fine to me. For the second one you would probably use a SFSB, but how are you going to keep reference to the SFSB for the duration of your Session? you would have to keep it somewhere, like your HttpSession. So you might aswell store all your temporary information in your HttpSession ie. use the first option.
Tom Tees wrote:
Some more thoughts...
What about "Catalog"??
Where is your "Buying Dept"??
Also, make sure you are modeling "Actors" and not People or Job Titles.
TomTees
Tom Tees wrote:Looks pretty good, but your Project Mgt System (or whatever) is an Actor to your primary Use-Case, right?
Also, I personally avoid <<included>> Use-Cases because it often leads people into "functional decomposition", although your use looks okay.
TomTees
Jimmy Clark wrote:Keep in mind that a framework and an application are not the same thing.
If your task is design a "framework" for building applications that move data from XML format to relational format, then in your mind you need to think about the differences between a framework and an application. A "framework" is a skeleton. It does not do anything on its own. It is used to help with application development. You need think about what developers needs to do to build an application that moves data in this fashion. AND, then think about what "you" can do to help "them."
Your objective and focus should be on helping application developers, not building an entire data processing application.
Frank Bennett wrote:There shouldn't be two relationship symbols connecting the Dice class and the Game class. There should only be one. When you want to "optionally" include multiplicity in the relationship between two classes, you add the number near the class that it applies two. In this case, it would be a small two.
Keep in mind that a Class diagram is typically for describing classes, not run-time objects. It is usually best not to include run-time information in Class diagrams. Any important information can be included as a Note, which is a very helpful UML tool.