Win a copy of Microservices Testing (Live Project) this week in the Spring forum!

Matt Lewis

Greenhorn
+ Follow
since Jul 26, 2004
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 Matt Lewis

As long as you can justify your diagram, you can do either. Personally, I did not show any Travel Agent classes in the diagram. I simply extended the BDOM
I included an actor or other component in the Sequence Diagram labelled "XXX Use Case", and used an <<include>> stereotype to show that the Use Case formed part of the sequence diagram.

This is described here - UML 2 Sequence Diagram Overview

It states

The method of modeling the inclusion of use cases using in Figure 7 is something that I first proposed in The Elements of UML Style although I have no doubt that others use this approach as well. I basically show the use case as a bubble across the top of the diagram, just like any other classifier, and show a message sent to it with the <<include>> stereotype. This is consistent with both use case diagramming and sequence diagramming practices.

Surely if it is a stateless session bean then you dont need to know which instance serves you??

The link given above is correct. You are able to cache the handle to a session bean object
This is one of those cases where you make your assumption and document it. I made the assumption that the system checked mileage availability and reduced the amount of available mileage by the applicable amount. If not enough mileage was available, the system returned a failure condition. This is not something in the requirements I had, but was an assumption that i made. In terms of the material produced, it only amounted to a condition statement on a sequence diagram.
As i understand it, because of the nature of HTTP, each request to a server from a browser is treated as a unique request. Therefore, request A will run to completion, as will request B on the server side. Design patterns such as the Synchronizer Token can be used to prevent the sending of duplicate requests.
It very much depends. Typically, all state will be lost when the server crashes. It is possible to replicate session state across chosen primary and secondary nodes. In this scenario, if the server went down in the middle of an operation, that operation would be lost. This is dependent on a clustered environment in which a managed server goes down, but the other managed servers stay active.

It is also possible to use the ejbActivate and ejbPassivate methods of a stateful session bean to write session state out to persistent storage. This allows some form of recovery.

Typically, if you wish to survive a server crash, entity beans are used or a custom solution provided, as state must be written to persistent storage
I showed sequence diagrams originating from a generic "client" as the business logic in the backend is the same for both the Java application and the Web application.

I also used Struts, and showed a sample sequence diagram showing how a request is handled using the Struts framework (ActionServlet, RequestProcessor, ActionForm, Action class and so on).

I believe that showing every action class used to process the request would bloat the sequence diagrams.
Part 3 is straightforward if you have rationally thought through your assignment. You are asked generic questions about what implementation mechanisms you used, and why you used them. This is information that you will probably put in your assumptions doc in part 2, and so you may find yourself duplicating this information.

Also, it is worth thinking about the QoS functions which formed some of the Part 1 exam - maintenance, availability, scalability, performance and so on