Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Big Smokes Cigar Shop question

 
Komandir Kozlov
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guys, who are working on this assignment or already has finished it and all others. After reading requirements ten times I still don't see any need for use of DB here from provided use cases. Is it possible? I mean that application will be kind of 'not production' w/o DB, but anyway as I understand we need only to complete supplied requirements and not to try to imagine other scenarios. I understand that we can point this in list of assumptions bla bla bla, but still need your view on this.

To make clear that I am not asking for concrete advice for implementation (which is of course prohibited), I just wondering if it is possible at all, as I don't want to loose points only because I didn't make all assumptions (and assumptions can be made recursively ad infinitum ) etc.

-----------
Komandir Kozlov
SCJP, SCWCD, SCBCD, SCEA (1)
 
Rumen Krastev
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Komandir Kozlov wrote:Guys, who are working on this assignment or already has finished it and all others. After reading requirements ten times I still don't see any need for use of DB here from provided use cases. Is it possible? I mean that application will be kind of 'not production' w/o DB, but anyway as I understand we need only to complete supplied requirements and not to try to imagine other scenarios. I understand that we can point this in list of assumptions bla bla bla, but still need your view on this.

To make clear that I am not asking for concrete advice for implementation (which is of course prohibited), I just wondering if it is possible at all, as I don't want to loose points only because I didn't make all assumptions (and assumptions can be made recursively ad infinitum ) etc.

-----------
Komandir Kozlov
SCJP, SCWCD, SCBCD, SCEA (1)


IMHO it would be un-realistic to design a system without DB, even simple flat files can be considered as DB, since storing information in permanent way is always required. In this particular case (I'm also working on this assignment) the DB is mandatory for storing user account's details (even it's not mentioned in use cases it's obvious the user need to authenticate) and also order information, e.g. when you close the browser before checkout and enter the website again next day/week it still keeps your shoping cart, right?
 
Komandir Kozlov
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rumen,

Thanks for your reply. But both your examples seem not very convincing for me. User accounting? Why do you think we should implement it even if we haven't been requested to? There are a lot of e-commerce sites which allow you to make full buying cycle without logging in. Moreover, I am sure that accounting is such functionality which couldn't be missed by our business analyst if was required. Regarding second example, it seems to me questionable to save shopping cart between sessions even with accounting. Most real-life ecommerces don't do this. Again, you are trying to mind up new use case - Shopping cart saving, but we wasn't required to do this!!!

I understand your point, but with the same success we can mind up many more use cases, which wasn't required. Where is the border line???
 
Rumen Krastev
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Komandir Kozlov wrote:Hi Rumen,

Thanks for your reply. But both your examples seem not very convincing for me. User accounting? Why do you think we should implement it even if we haven't been requested to? There are a lot of e-commerce sites which allow you to make full buying cycle without logging in. Moreover, I am sure that accounting is such functionality which couldn't be missed by our business analyst if was required. Regarding second example, it seems to me questionable to save shopping cart between sessions even with accounting. Most real-life ecommerces don't do this. Again, you are trying to mind up new use case - Shopping cart saving, but we wasn't required to do this!!!

I understand your point, but with the same success we can mind up many more use cases, which wasn't required. Where is the border line???

It's up to you where you'd put the border line, that's why there is assumptions section, hence if you decide no DB, it won't be mistake, but this might open questions about reliability (check about ACID) IMHO.
Just to mention, the shopping process in real life is asynchronous and long-time consuming, definitely longer than a single web session. Think about sending mail with receipt, confirmation mail, report mail for shipping progress, promotion emails, credit card fraud detection, etc. Often the exact payment processing is taking more than one day for fraud prevention reasons and so on and so on. All of these actions suggest storing user info in permanent way. Anyway, these things are not in the requirements and as I said it's completely up to what way you'd choose. I designed my architecture with DB because the system won't be reliable enough if doesn't store transaction, user and order information.
 
Komandir Kozlov
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just to mention, the shopping process in real life is asynchronous and long-time consuming, definitely longer than a single web session. Think about sending mail with receipt, confirmation mail, report mail for shipping progress, promotion emails, credit card fraud detection, etc. Often the exact payment processing is taking more than one day for fraud prevention reasons and so on and so on


I agree that shopping is long process, but most of this process - selecting available items, reading reviews, comparing opinions - usually is taken part outside of ecommerce site. When you made your choice you just select site with cheapest price and go there to buy items. And I am pretty sure that this last part of shopping is quite quick. About payment - I also think that nowadays it's exception when payment is not done instantly. Anyway, nothing prevents you from extending lifetime of http session to, say, 30 minutes and also put some session restoration information to hidden fields.

It's up to you where you'd put the border line, that's why there is assumptions section, hence if you decide no DB, it won't be mistake, but this might open questions about reliability (check about ACID) IMHO.


Good point. Anyway we would have cluster here. As session is managed object and every WAS has automatic mechanisms like session serialization and session replication, so I don't see problems with reliability in propely configured cluster. Anyway, in case of crush it's always possible that user hasn't saved his shopping cart, so DB is not of big help here. Or you update cart instantly? (problems with concurrency and performance)

I designed my architecture with DB because the system won't be reliable enough if doesn't store transaction, user and order information.


Yes Db is required for order review, but again this is completely new use case. And we still can manage orders through order mails anyway, so it's not so big deal.

Thanks for your replies, we have quite useful discussion.
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does your check-out use case include a step for entering a shipping address? If no, then where does it come from?
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Where does your product catalog come from?
 
Rumen Krastev
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
J J Wright wrote:Where does your product catalog come from?

Not only this - almost all information in modern web sites is dynamic, therefore configuration/customization is an essential feature leading to logical decision to store this data in DB, but I should admit that he is right that nowhere has been mentioned this in use cases, neither system requirements, so in sake of theory I think he could provide design without DB and still pass the test. It even might be explicitly mentioned in assumption section.
 
Komandir Kozlov
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
J J Wright wrote:Does your check-out use case include a step for entering a shipping address? If no, then where does it come from?


Yes, I don't see any problems to have section for shipping address in check-out page along with payment info etc.

Where does your product catalog come from?


Yes, it was big question for me as first use case starts from "User selects product category" and question where it comes from is again out of scope of presented use cases. So, I have assumption here, that it comes from Inventory subsystem. To have catalog in DB means that we have to maintain it too with full CRUD and this is again big additional use case. Also, what is frustrating for me regarding categories - PetiteCigar, StandardCigar and FlavouredCigar mentioned in domain model are, as I understand - product categories. How have you interpreted this? You have those categories hardcoded in DB and if needed add there some more categories?

Not only this - almost all information in modern web sites is dynamic, therefore configuration/customization is an essential feature leading to logical decision to store this data in DB, but I should admit that he is right that nowhere has been mentioned this in use cases, neither system requirements, so in sake of theory I think he could provide design without DB and still pass the test. It even might be explicitly mentioned in assumption section.


Yes, Rumen, you are absolutely correct, but we are required to fulfill requirements of assignment and not to build real-life app, as I understand.

P.S. Jonathan, how is your assignment? From topics you have created I see that you already posted it some time ago. How long have you been waiting for results already?
 
mimi mang
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Komandir, your point is interesting! It's possible to implement a system without DB. but you have to have some sort of data repository such as system files. For example, you need provide shipping method selections and credit card type selections. such selection information should come from business tier other than harcoded in your jsp files.

Although you can argue about that here but there are some best practices in this field. The assignment has an availability requirement. such availability means many things not just mean your web site is still running.
 
Komandir Kozlov
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's possible to implement a system without DB. but you have to have some sort of data repository such as system files. For example, you need provide shipping method selections and credit card type selections. such selection information should come from business tier other than harcoded in your jsp files.


Of course, I am not going to hardcode shipping methods in jsp . Look, with shipping methods you always will be tight-coupled to API provided by those shippers. For every shipping company you would have kind of connector to communicate with their api. And when you will be adding new shipping company it's unavoidable - you should build new connector wire it to processor etc. It's impossible to achive any common extensibility here to use DB for this purposes. So some config/property files is enough here for me. The same with credit card types - there are 4-5 card types you will support and it's unlikely that there will appear some more in the nearest time, so config file is enough. So if you mean by system files some kind of config/property files, yes they are required anyway, but it's far away from DB.

Although you can argue about that here but there are some best practices in this field. The assignment has an availability requirement. such availability means many things not just mean your web site is still running.


That's interesting, what do you mean here?
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I don't see any problems to have section for shipping address in check-out page along with payment info etc.


Are you saying your requirements explicitly include an "enter shipping address" step in the main flow of the check-out use case? Or are you saying, I don't see a problem with adding my own steps in order to fit my design? I'd be very cautious if it's the latter.

Leave the business decisions to the domain experts.
 
Komandir Kozlov
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
J J Wright wrote:
Are you saying your requirements explicitly include an "enter shipping address" step in the main flow of the check-out use case? Or are you saying, I don't see a problem with adding my own steps in order to fit my design? I'd be very cautious if it's the latter.

Leave the business decisions to the domain experts.


No there is no such step in main flow, also as no step to login in order to be able to check out or use case for user accounting, so I don't understand your point here. You want to say that you were able to design application without any assumptions/additions? Or want to say that addition of step for logging in is better than addition of step to enter shipping information?
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't understand your point here


Use cases can obviously have pre- and post-conditions. I see nothing wrong with making an assumption that users must be logged in prior to executing the check out use case. I would, however, be cautious about making changes to the actual structure of the use cases. Of course, that's only my opinion. I'm certainly no authority on how Sun view this, nor would I profess to be. As such, it may well be perfectly acceptable to add your own, well documented, steps.
 
Komandir Kozlov
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok. I see your point now. I like your idea of pre and post conditions it seems pretty logical for me. I think shipping info can be also provided as pre-condition to check out use case.

Have one more question - How you interpreted StandardCigar, PetiteCigar FlavouredCigar in domain model? The only logical explanation is product category, but does it mean that there shouldn't be other categories? Does it mean that categories are static? Those 3 entities are absolutely out of model for me.
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This thread might help
 
Komandir Kozlov
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
J J Wright wrote:This thread might help


Yes, I've read this topic already. So, you interpreted domain model as conceptual and didn't included StandardCigar, PetiteCigar, FlavoredCigar to your class diagram at all? It makes a lot of sense for me to use generic ProductCategory instead of those 3, but is it allowed, as in assignment it is stated that objects on domain model are key objects and should be addresed in our design?
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It makes a lot of sense for me to use generic ProductCategory instead of those 3, but is it allowed, as in assignment it is stated that objects on domain model are key objects and should be addresed in our design?


I think this is fine. The business entities in a domain model don't necessarily have to be reflected "as is" in the design model. OOA&D is obviously about keeping the representational gap between the two as low as possible. If you assume the business entities are product categories I think you still achieve that.
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've just been reacquainting myself with this thread. It's probably best if we limit discussion to generic assignment questions.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic