I would represent them both the same way (as subsystems). This is how Cade-Roberts represent external systems in the example in their book.
What is HTML?
is enough for me.....
Whoops! Sorry for the confusion. I was just being silly and adding to the OOAD acroynm...
OORADPw/UML =
OO - Object Oriented
R - Requirements
A - Analysis
D - Design
P - Programming
w/ - with
UML - Unified Modeling Language
just a soon to graduate college kid with a special place in his heart for java.
It's really an OORADPw/UML book.
Hi Ariel and Mark,
Thanks for sharing your experiences. They are of immense help to us.
I have one doubt. For technologies like RMI, JMS, EJB or client -server in general were there any code examples on the exam ?
Section 6: Java Platforms and Integration Technologies
* 6.1 Distinguish the basic characteristics of the three Java platforms: J2SE, J2ME, and J2EE, and given a high-level architectural goal, select the appropriate Java platform or platforms.
* 6.2 Describe at a high level the benefits and basic characteristics of RMI and threading.
* 6.3 Describe at a high level the benefits and basic characteristics of JDBC, SQL, and RDBMS technologies.
* 6.4 Describe at a high level the benefits and basic characteristics of JNDI, messaging, and JMS technologies.
Section 7: Client Technologies
* 7.1 Describe at a high level the basic characteristics, benefits and drawbacks of creating thin-clients using HTML and JavaScript and the related deployment issues and solutions.
* 7.2 Describe at a high level the basic characteristics, benefits, drawbacks, and deployment issues related to creating clients using J2ME midlets.
* 7.3 Describe at a high level the basic characteristics, benefits, drawbacks, and deployment issues related to creating fat-clients using Applets.
* 7.4 Describe at a high level the basic characteristics, benefits, drawbacks, and deployment issues related to creating fat-clients using Swing.
Section 8: Server Technologies
* 8.1 Describe at a high level the basic characteristics of: EJB, servlets, JSP, JMS, JNDI, SMTP, JAX-RPC, Web Services (including SOAP, UDDI, WSDL, and XML), and JavaMail.
* 8.2 Describe at a high level the basic characteristics of servlet and JSP support for HTML thin-clients.
* 8.3 Describe at a high level the use and basic characteristics of EJB session, entity and message-driven beans.
* 8.4 Describe at a high level the fundamental benefits and drawbacks of using J2EE server-side technologies, and describe and compare the basic characteristics of the web-tier, business-tier, and EIS tier.
Mark,
I changed the relationship exactly between Segment and Flight because of the change of equipment but the same flight number. I made perfect sense to me at the time and I am very sure there are other ways to represent it.
Segment1 -> Flight123->Equipment123
-> Flight123->Equipment456
I just thought about how my itinerary for that trip was structured and with the printed Itinerary that I was given the stop over in Sydney and the change of plane was never mentioned at all. It was a internal representation that was still very relevant for this application as it impacts seat booking and also supports the concept of other customers booking Segments that may be parts of other Segments (i.e. Joining the flight in Sydney to continue onto San Fran, using my example from previous posts).
Hi David,
I think there are any number of approaches and solutions to the Itinerary/Segment/Flight etc BDM issue. You just need to be clear in your own mind on how you apply it to the problem domain and constrain your solution with relevant assumptions. My way is only one approach and given the amount of discussion on the list over the last few years I have seen a number of approaches that are all valid and got very good marks.
I changed the BDM to fit with my solution making Segment and Flight 1 - 1..* Given I have tried to explain this a few times, rambled alot and have probably confused everyone more I will try to highlight a real life example I found very relevant and enlightenting to validating my model.
I took a flight from Melbourne, Australia to Washington DC, USA and lets just stick to one way. I did this in real life, took 30 hours which was hell but that is not the main point here
Itinerary had 2 Segments.
- Segment 1: Melbourne to San Fransisco with flight number 123.
- Segment 2: San Fran to Washington DC with flight number 456.
Segment 1 was where I didnt like the original BDM. Basically Melbourne to San Fran was really Melbourne->Sydney->San Fran. Some passengers only went form Melb->Sydney as overflow on domestic flights I guess and some passengers joined in Sydney to go on to San Fran. We actually changed aircraft type in Sydney but kept the same flight number. I described this scenareo in detail in my assumptions/design document to defend my decision to change the BDM ever so slightly and the model was applied.
Segment 2 was a nice and simple so no issue there with the old BDM.
In thinking about scenario 1 I just didnt like the way the original BDM handled it. That doesnt mean mine is the only solution. Leaving the BDM as is and coming up with alternative solutions could be 100% correct. I am pretty sure my good mark came down to fully documenting my assumptions and design rather than this approach being the only valid solution.
David, hope that help... or I have just confused everyone more
Rgds,
Matt
Basically Melbourne to San Fran was really Melbourne->Sydney->San Fran. Some passengers only went form Melb->Sydney as overflow on domestic flights I guess and some passengers joined in Sydney to go on to San Fran. We actually changed aircraft type in Sydney but kept the same flight number.