SC Johnson

Robin --
Take a look in the Core Servlets and JSP book -- they have a section on using an applet as an HTTP client. You can use the same code inside a Session Bean (it has nothing to do with Applets).
I've used similar code in my work.
Steve

I didn't really do much for the application client -- it was the one glaring thing missing from my submission.
I did include all JSP's in the diagram, my rationale being they are "J2EE Components" as cited in the assignment text.
Steve

Hi --
I guess they didn't update the assignment text, but I'm pretty sure everyone will be graded on the 44/44/12 scheme -- bummer, since my score would have been higher using the 40/40/20
Anyway, the non-functional requirements are things like: scalability, maintainability, reliability, etc. A software designer is responsible for the *what*, an architect is responsible for the *how*. Look at the number of customers, agents, legacy requirements, security, etc. That is the focus of the assignment -- not building a web app.
I looked at petstore, but didn't use it. If you read the J2EE Patterns book (and understand it), you're halfway there.
If you're not an IT guy, talk to some sysadmins or network engineers about security, loads, and bandwidth requirements.
Good Luck,
Steve

Hi --
I started with the data model, assuming the domain model objects as tables (not a good assumption, but a starting point). As I developed the data schema, things started getting clearer. Whenever things got confusing, I used the use cases as the point of reference. The domain model may be dodgy, but there is nothing wrong with the use cases, IMHO.
Hope it helps,
Steve

Here's a repost of what I put on the yahoo group:
Just got the results back, 4 weeks and 1 day after taking part 3:
The maximum number of points you could have received is 100, minimum
to pass is 70. Class Diagram (44 maximum) ......... 42
Component Diagram (44 maximum) .................... 39
Sequence/Colloboration Diagrams (12 maximum) ...... 12
Pretty happy with the results, waiting for them is a pain
Thanks to this group for the help (mostly with Part I). Here's some
advice if you're interested:
1) Like most news groups, ignore 80% of everything said here about
the project. There are too many different ways to execute the
solution, and deconflicting the advice from the group (and figuring
out who is full of BS) can drive you nuts.
The solution needs to make sense to *you*, and you should be able to
justify your decisions. I modified the domain model, and gave a good
explanation of why I did it, how it helped simplify the solution, etc.
2) Do the project iteratively -- treat it like a real OOA/D
exercise. It will save time in the long run. If you don't know
OOA/D, this project is a perfect way to learn. It's something an
architect should know.
3) Pay attention to non-functional requirements. That is the
architect's job.
Cheers,
Steve

Great Score G!
not to nitpick, but make that SCJA into SCEA. People might confuse your cert with the older, discontinuted certification.
Steve

A domain object does not imply a persistent class. Domain objects are *analysis* objects. They exist solely to help the analyst undertand the relationship between concepts in the system.
Many domain objects end up as persistent classes, but don't assume you are creating an ER diagram.
Once again, the domain class diagram is a communication tool between the analyst, customer, and eventually the designer.

part one covers 1.1 only
part two and three are up to you (use 2.0 if you want to), but plenty of people have passed with 1.1 only

Stop and think about it a little. Or better yet, go to a real airline's web site. Notice you can search for flights, and build an itinerary without logging in.
The use cases state when you *must* be logged in to perform certain tasks -- in fact, they're throwing you a huge hint on how the solution will be architected! See above post about fast-lane readers for more detail.
<soap-box>
I've noticed certain ranch members are always bad-mouthing the part 2 assignment (not the original poster in this thread, mind you), citing conflicting requirements, etc. I can only suggest reading the requirements fully and --heaven forbid-- go through an OOA/OOD process to design a solution.
I know of only -1- problem in the assignment, and the assignment itself calls attention to it!
If anyone has aspirations of becoming a java architect, they'd better get used to having worse requirements than Sun gives you in part 2!!!
</soap-box>

It is a good idea to determine when the information is committed to the database. Remember there is a lot a "customer" can do in the system without buying anything, and without even logging in. You want to avoid committing resources (like database) to these lookie-loos.

Congratulations!
I looked forward to part 2 until I started it
I didn't enjoy it until it was finished
Cheers,
Steve

Did sequence diagrams that showed core for both web and application, then made sequences that showed pattern for web and app client to get to the "core".

I disagree on part of that.
There is no need to change the use cases. They are solid.
The domain model is *NOT A SOFTWARE DESIGN DIAGRAM* it is a tool to show relationships between *ideas* or *concepts* in a system. There is absolutely nothing wrong with adding or modifying relationships between these concepts to match the use cases.
In my submission, I asserted that the domain model is not in sync with the use cases. I took appropriate action.