1) Is annotation in parentheses an UML standard to describe stereotype (without reference to profile)? Also, is it not necessary to indicate which EJB version is used? Also, which version of UML is this?
-I used a stereotype of <<@Stateless>> rather than the parenthesis. It's not standard UML, but it communicates the idea. I indidicated the EJB version in my summary and not in the diagram. The book seems to use a mix of UML 1 and UML 2.
- Did you use this because you did not want to extend the core profile? This is understandable; however, using arbitrary symbols in a text books without proper explanation could be misleading to test takers. Ivar Jacobson wrote, "Most software developers speak pragmatic UML. Not perfect—some special words are rarely or never used. Sometimes the blur of their models leads to misunderstandings. However, generally speaking, it works well." IMHO, there is discernible difference between test taker and text book writer.
2) Although I may sound a little different, IMHO, how would you hold states between client calls if you have stateless EJBs only, e.g. BidManager, etc.? I say this particularly since you have to make multiple calls such as findBid(), createBid() to complete a transaction as per the non-private methods. Are they grouped somewhere else to create one atomic unit that is not apparent? You can maintain conversational state in so many ways but only thing such solution is not apparent from the class diagram.
- Why not store the data in the HttpSession? Another thing to put in the summary of design. Class diagrams never stand alone to describe a design.
- My question was different: nothing is explicit from the diagram. I don't think it is apparent elsewhere.
3) I am not sure but some classes, e.g. AvailabilityItem looks more like 'being part of' AvailabilityNotice that refers to a directed composite relationship rather than the catchall both-ways association. Is it that aggregation, composition, and directed association are not required in SCEA? This actually softens the standard of compliance, which should be declared by Sun/Oracle so that test-takers may spend their times in a better way.
- Hard to tell what is required. I did include these relationships where important.
- My question was, why waste test-taker's time by mentioning "standard UML only" in the assignment when you use only a subset of it; that too, not in a standard way?
4)Is it that the authors generally ignore the guiding principles of GoF patterns? I ask this questions because the whole class diagram is built on inheritance only. Moreover, if I am not mistaken, abstract nature of classes, e.g. User, Characteristics, are not captured by standard UML means.
- I see dependency (uses) looking at it quickly.
- I would rather say that does not fulfill the recommendation of the g04 to use loose coupling since A depends on B simply means A need to change when B changes and does not go much beyond.