Carlos Duarte

Greenhorn
+ Follow
since Jun 24, 2005
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Carlos Duarte

Originally posted by Vinays Singh:
A requirement is that customer selects seats. My question is
a) does this mean he selects which seats he wants..? This does not happen usually.
b) If yes, do we assume that the seats remain same for all legs/segment and even for return flights ?
c) Do wee need to lock the records when cutomer is selecting seats as some other consurent user might block that seat. Also hwne the payment is through, that seat might have already been booked by some other passenger?
I am a little confused with this aspect of requirement.
Your help is appreciated
Vinay




a) It's your call here. Taken alone, this quote is subject to interpretation (either asking seat number, or just class). Notice, however, that there may be references later in the use case which could imply one specific answer. Whatever you assume, write it down clearly.

b) I don't think so. I believe (from a customer standpoint) that if the system lets me choose seats, it should allow me to choose specific seats for each leg - after all, a seat available on the first leg may be already booked for the next leg (by someone whose initial departure was at this second leg's departure). The same happens for return flights - I think it is reasonable to ask for each leg on the return flight (or don't ask at all - but not asking for a seat number for every flight - equipments can be different!)

c) Think of this use case as if it was a transaction. You will see that it's the old optimistic-versus-pessimistic-lock dillema: if you lock the seats as they are chosen, you lower the chances that somebody cannot complete the "transaction" at the end - however, you will need some sort of rollback or periodic cleanup. If you just let go and do the real booking only at the end, there is a possibility that your user will have to go back and select another seat (because somebody took the first one). Consider the trade-offs - either solution is acceptable, as long as you explain how to implement it, and make sure no overbooking happens (in real life it indeed happens, but for completely different reasons

Hope it helped!
[ August 11, 2005: Message edited by: Carlos Duarte ]
My Part I score was 81%. It is not first-rate, but I think it was more than enough to let me move along. You probably have a good understanding of what you did (and why you did it) on part II (both in terms of functional and not-functional) requirements, so don't worry.
It's easy: just send an e-mail to SunCert@prometric.com informing your id at CertManager/Prometric (mine is an spNNNNNNNNN number) telling them you are almost finished with your SCEA Part II assignment, and you would like to have upload permissions. In a couple of days they will contact you, probably saying the permissions are ok.

Good luck!
Hi!

I used Jude, and for both cases I used what the software had had: for the sequence diagram I represented the actor using an object, descrbing it just as if it was the actor symbol. In the component diagram, I packaged components inside bigger components (you can nest them).

I don't know about the component diagram (lost a few marks here, but mine had other problems, I guess), but the Sequence diagrams got full marks, so don't worry too much about this kind of detail...

Best regards,
Carlos
Another helpful thing for those who already submitted are anxious about their results: they show up when you click on "Test History" on CertManager (http://www.certmanager.net/sun_assignment) - in the same place where you can already see your Part I results.

They will appear as a paragraph in the same format (with a "details" button that shows you the score for each kind of diagram).
To everyone: Thank you very much!

(and "obrigado, valeu mesmo!" where applicable )
Vinay,

Let me see if I can help:

Originally posted by Vinays Singh:
1. How would SSL affect the design ?
2. Itinerary,segment and Flight , if you display them in class diagrams , does this mean they would be persistent enitities ? I could not find any logic of storing segemnt because if I store flight1,flight2 against an itinerary, it would imply that this itinerary has 2 segments
But then if you don't persist, should it appear as entity ?
3. How would you display components? I am not very sure about it! Would you first display packages and then drill inside to show classes in them ? Or you just display all the classes jsp in one page but that would clutter the things.
4. Swing client, did you show some where or just mentioned in assumptions?



1. Wherever I chose to use SSL (or any other "wrapper" technology) I mentioned it on the assumptions documents, and on the message exchange on the sequece diagram (for example: "send https request for xxx" instead of "request x"). By the way, I used a mixture of method names and descriptive messages on the sequece diagrams, picking whichever made the idea clearer;

2. My class diagram does not deal with persistence. It just shows the classes (the ones on the BDM and a few extra ones), regadless of their lifecycle. The component diagram shows all their persistent counterparts - however, a few of them are compositions (i.e., persistent class A stores objects of class A and also objects of class B which "belong" to A and most of the time will be retrieved by people who retrieve A), so I have fewer persistence classes (around six) than persisted objects (around nine or ten).

I mention this in the assumptions document (the parsistence technology used and the fact that some object hierarchies are persisted by the same persistence class) and the sequence diagram allows the examiner to see this in detail - maybe if my sequence diagrams were less detailed, I would have shown some of it on the component diagram - but not on the class diagram.

But the core of your question is about which of them to persist. And the answer is "it depends". As you probably have noted searching this forum, a flight/segment/itinerary (and even a leg) can have different meanings. Which objects will be persisted will depend on your definitions for each class. For example, one could assume that flights are pre-existing entities on the use cases, and store just segments. I suggest that you write down a paragraph explaining what each entity (class) means, and try to explain (also in text) how things like multi-legged flights would be represented on that domain. It will show you which extra classes you need (if you need them) and also which of them should be persisted.

3. I went on the "simple is better" lane here - showed one component symbol per layer (things such as "Presenatation", "Business Logic" and such), and, inside each component, a component representing each class - with the already mentioned exception for JSPs, to avoid clutter.

4. Just mentioned (with some rationale describing how the Swing classes would be implemented, how authentication and other things would work). Don't know if I lost marks for not showing this components in any diagrams - however, I was afraid to make some mistake here. Maybe showing the classes here wouldn't hurt - but I wouldn't like to draw Sequence diagrams for them (and I have a hard time to show this kind of details without at least prototyping a sequence diagram), so I didn't show.
Oh, forgot one "default question": I used Jude to draw the diagrams. It works very well on Mac OS 10.3 (yeah, the menu bar is in the wrong place, but it seems to be mostly Swing's fault). The only problem I had was due to Mac OS's default memory settings for double-clicked .jar files. Increasing Jude's memory by calling it manually, e.g.:

java -Xms32m -Xmx256m -Xss1m -jar /Applications/Jude.jar

solved every issue.
It seems somebody caught up the late work at Sun/Prometric today!

I took the Part III examination at June 29, but uploaded Part II only at June 30 - as it happens often, I forgot to ask upload permissions...

The breakdown:

Class Diagram (44 maximum) .......................... 40
Component Diagram (44 maximum) ...................... 39
Sequence/Colloboration Diagrams (12 maximum) ........ 12

Let me answer the default questions , without, of course, going into infringing details:

My background: I have around 14 years of professional software development experience - it is hard to say how much of it is "architecture", but I believe my role has been more architectural-centric in the last four or five years. Half of these last years' work was Java/J2EE, and the other half Win32/.Net/"LAMP". The FBN system itself is not what I would consider challenging, but Sun's requirements for delivery made me sweat quite a bit. .

Think I spent around 80 hours working on it (including reading and "thinking about it" time), but never more than two or three a day, except in the last few days. Didn't look to Petstore (had studied a few parts of it in my first days on J2EE). I used the books I had used previously for Part I: Allen/Bambara's SCEA book, and the Brazilian Portuguese translations of Design Patterns, Core J2EE Patterns and UML Distiled. And *A LOT* of JavaRanch. Read it almost daily, and searched it whenever I got stuck. It really pays off!

My assignment had one class diagram, one component digram (each layer was a big component, with classes depcited as smaller components), four sequence diagrams and a four page assumptions HTML. In detail:

Class diagram:

A few properties (just the ones that I thought someone would be asking whether they beleived to this or that class) and fewer methods (only used methods to detail responsibility). It was really an extended BDM, with around 15 classes. It was technology-agnostic (no EJB stuff, for example) but with one or two transport objects that maybe should be left out.

I did not change BDMs cardinality or anything about it. And yes, I puzzled myself with flight-segment-equipment, but there are quite a few ways to keep things as they were and cope with your architecture's needs. Think out of the box and - most important - write detailed definitions for what is one thing and what is another thing. Play God: if the real-life notion of, sey, segment is incompatible with the BDM, define that segment is something else and move along. Just write it down on your assumptions document and it will all fit in the end.

Component Diagram:

Most classes which were not on the class diagram appeared as components on the component diagram. A few clarity tricks were used - for example, instead of having every JSP, I had a "JSP/view" component (with a note showing JSP names). Keep in mind that this diagram must show all J2EE components - but you can improve readability without omitting information.

Sequence Diagrams:

They were *very* detailed, showing in detail the exchanged messages (mehtod calls) between classes, from the very front JSPs to deep into EJBs and external systems. Being so picky is not not a requirement for SCEA (there are lots of peoople who pass with simplified sequence diagrams), but it is related to my personal modeling methodology: I start with a very bare class diagram (the BDM offered by Sun matched it very well) and start drawing sequence diagrams according to use cases. This work reveals the architectural needs, which I use to fill the component diagram, and also shows the detailed relationships between classes - which help me improve the Class Diagram.

Assumptions:

I went verbose on this one: four pages with diagram clarity decisions, the assumptions themselves, architectural and design choices and, in the end, the links to the diagrams. Bullet-oriented, with very simple formatting (as crude as Sun's assignment document, let's call it justice ). It started as my personal notes, and was developed along with everything else. It's motto was "if someone reads it, he/she will understand why did I choose X instead of Y, even if he disagrees".


My personal advices:

- Don't worry about Part III. Spend this energy on Part II, always questioning if it fits all of the theory that you used in Part I (see section 2 of Part I's exam objectives in http://www.sun.com/training/catalog/courses/CX-310-051.xml and you will understand what I mean). This make your architecture so solid that you will have no problem at all with explaining or justifying it.

- Take Part III as soon as you finish part II, but REMEMBER to ask upload permissions at least a few days before you need it - Sun's Sharon kindly solved my troubles with it, but why take chances? You are already nervous enough!

- Read the requirements until your eyes pop out. Seriously: most of the confusing areas were clarified after I re-read the requirements.

- This forum is, by far, the *very best* resource of information on the web. Really. The guys here rock, the discussion is very high-level, and I barely could help other people, because by the time a question was posted, complete answers flourished almost immediately (if it did not happen to you, use the search - a few questions get re-posted way too often).

- HOWEVER: don't take everything on the forum as the absolute truth - the absolute truth does not exist, and the only thing that you should assume to be close to that is the requirements. Listen to John, listen to Paul, but make your own choices. There is very little "right or wrong" here, but there is a lot of justification needed for choices.

Other than that, thanks a lot to everyone participating in this forum. I would be completely lost without it! If I can help with anything, just drop a note!

Best regards for everyone. I'll go celebrate now!
Don't worry: Part II is, in fact, enough preparation for part III. Without spoiling anything, I can only tell you will be asked some "how"s and "why"s on some aspects of your architecture. Preparing the materials by yourself is all you need.

[]s
Hello!

I also used client-side session management for Traval Agent application (and Web-Container based session management for Customer application). But lots of other people here did otherwise. In my opinion, there is an scalability advantage into not tying session management to the EJB tier, but you should weight this in contrast with the code/setup reuse and other advantages that a backend-managed session can offer.

Decisions, decisions, decisions... that's all Part II is about!
I am using Jude (on Mac OS 10.3), and it is working fine. I miss a few tweaks from Together - such as having the sequence diagram starting with an actor symbol instead of an object (I am not sure how much UML-compliant is this, but it surely helps non-experienced people to tell things apart) - but this is cosmetic and can be resolved with some graphic editor.
Hi! I am 30, passed Part I almost a year ago. Didn't work too much on Part II since then, but started again last month (since my voucher for part III is due to the end fo ths month). Think I got around 60% of my work on diagrams completed.

I am from S�o Paulo, Brazil.
Re-reading your message, maybe it was more about where to use return arrows than where was the return arrow command... I used return arrows after the end of the flow, but only where they helped understanding. If the return parameter was too obvious on the flow, I left out the return arrow. Remember: clarity is your first priority, don't clutter more than you need to.