John Nk Wu

Hi folks,

Judging from the earlier discussions, I've got the same oil company question as some other did. However, I still feel doubtful on why the "auctioning marketplace" can be missed out from the "Use Case" diagram given in the assignment file since such system actually plays a fairly substantial role. It shall include such functions as (i) register bidders/sellers, (ii) take auction offers, (iii) take bids for each offer, (iv) set up auction start/end time, (v) determine winning bids, (vi) notify SuD auction results (v) transfer winner's details, ... In aggregation, these functions shall introduce heavy interactions to the SuD. So, is it really ok for us to just put all these factors down into Assumptions, without refining the 'Use Cases' or anything in our deliverables to be submitted?

Another aspect I'm still pondering is the 'recovery design'. The SuD includes various Web Services interactions. In my real life projects, we won't assume them impeccable, but have to design the recovery logic so that any failures arising in these interactions can be detected, and recovered. E.g. we ask the external system to update their DB record using Web Service. The external system has updated the DB record successfully. But, when it returns a reply through Web Service, it fails. As a result, our system will consider the external system fails to update their DB, though actually they did. Addition logic is therefore put in place to detect such kind failures/discrepancy, and try to recover them.

Any advice?

Regards.
John