Win a copy of Pro Spring MVC with WebFlux: Web Development in Spring Framework 5 and Spring Boot 2 this week in the Spring forum!

Komandir Kozlov

Greenhorn
+ Follow
since Jun 04, 2008
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 Komandir Kozlov

I had no chance to look at new scea book, because of stupid policies of safarionlines has against my country (it's considered as country with high risk of card fraud ), but what regarding first SCEA book - level of detail provided there seems to me very reasonable, think we should provide something similar, maybe just little bit more fine grained (as with methods in class diagram). Components used in sequence diagram, because they correspond to classes there, there are no abstraction of family of components there. And such approach is also valid, although is little bit old-fashioned.

My main advise - don't panic, everything will be in place after you will do some work.

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?
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 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?

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?
Andrew, I have assignment in front of me. And there is directly stated that for part 3 short answer you can get 24 point at max. So, if there is no resubmission of part 3 you will stay with points you got in previous essay or what? Also I am not sure that essay still will be relevant if you resubmit assignment.

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?

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.
Number of servers - probably yes, you can point this info in your deployment diagram, but CPU and memory... it seems to me too much. Anyway you can point them in list of assumptions, if you have special requirements for performance etc.
You should treat part 2 and part 3 as one part. As they graded together. Moreover, it's impossible to fail exam only because of part 3, because it could bring you only 24 points in best case. So, if you will fail you will need to retake both part 2 and part 3. How do you like this Sun's trick?
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???
Hi guys,

Can you tell me what size of class and component diagrams is OK? How many classes your diagrams included? As it's absolutely unclear for me how fine-grained they should be.

Thanks a lot for your answers

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)
Thanks for your answers . Problem was solved with use of annotations. Hope it would be helpful for someone.
13 years ago
Hi,

How could I define namespace uri and prefix for nested elements in schema using JAXB?

I have next schema
...
<xs:element name="RequestXml">
<xs:complexType>
<xs:sequence>
<xs:element name="oInputXml">
<xs:complexType>
<xs:sequence>
<xs:element name="B2BAvailabilityRequest" >
...

and next code which deal with this JAXB generated beans

ObjectFactory factory = new ObjectFactory();
RequestXml requestXml = factory.createRequestXml();
RequestXml.OInputXml oInputXml = factory.createRequestXmlOInputXml();
RequestXml.OInputXml.B2BAvailabilityRequest req = factory.createRequestXmlOInputXmlB2BAvailabilityRequest();

// fill req here

oInputXml.setB2BAvailabilityRequest(req);
requestXml.setOInputXml(oInputXml);
JAXBElement<RequestXml> jRequest = factory.createRequestXml(requestXml);

Problem is that I could define namespase uri and prefix only for JAXBElement. But I need also to define prefix for oInputXml too. I could create JAXBElement from RequestXml.OInputXml

JAXBElement<RequestXml.OInputXml> oXml = factory.createRequestXmlOInputXml(oInputXml);

but then it can't be nested in JAXBElement<RequestXml>.

How could I define namespace prefix for xml element which would be generated from this bean? Should I do this in schema or there is programmatic methods?

Thanks in advance,
Komandir
13 years ago