aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Business Model Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Business Model" Watch "Business Model" New topic
Author

Business Model

Girish Mohite
Greenhorn

Joined: Jan 29, 2009
Posts: 13
Hello

I have just started with my part2.It appears that the assignment that i received has many errors in it.
I have come across few use cases where the roles specified are exactly reverse to the ones they should have been.For example like it mentions supplier instead of employee and so on.
I am very sure that this might be a print mistake.

however looking at the business model i have come across a very basic question

1) can a employee issue request for more than 1 parts in its request to invite suppliers to start bidding?

2) I think the answere to point 1 above must be yes because as per the domain model one request can have multiple purchase orders asociated with it.
But this also means that any supplier can only part fulfill the request.

Can someone validate this?Or the cardinality might be incorrect between request and purchase order?


Regards

Girish
deepak adlakha
Ranch Hand

Joined: Jul 27, 2001
Posts: 325
that's the challenge this part 2, we dont have any to clarify our doubts.

How about making few assumption and based on your solution on that and you can mention the same in assumptions section about your assumptions. Like can't you assume there will be one request only for one part ?
Girish Mohite
Greenhorn

Joined: Jan 29, 2009
Posts: 13
Thanks for your inputs Deepak.

I agree the model will be much cleaner if we assume one req for one part type.However this contradicts the cardinality between req and PO (1 req can have many PO)
Though one can assume that 1 req has 1 part requests but different schedules.This way the relationship between req and PO can remain intact.Any thoughts?
deepak adlakha
Ranch Hand

Joined: Jul 27, 2001
Posts: 325
I am under impression that, if something is not right or not clear in domain model after reading it several time, then few assumptions can be made and solution can be based on that. If any one wants to comment on that or have some other thought ?
Teja Saab
Rancher

Joined: Mar 08, 2010
Posts: 152
I am under impression that, if something is not right or not clear in domain model after reading it several time, then few assumptions can be made and solution can be based on that. If any one wants to comment on that or have some other thought ?


Here are my 2 cents on this.

While we can make any assumptions we want in part 2, we need to ensure that those assumptions are reasonable. In other words, we cannot make an assumption that makes it very easy for us to architect a solution. Needless to say, the business domain model is provided that way to test how we can architect a solution for a complex problem. Even in real life, the business model is generally created by a business analyst who doesn't care much about the technical implementation of the solution. We cannot go back and ask the business analyst to change the model to make it easy for us to architect a solution.

I think the key in part 2 is to architect a solution that solves the business problem and addresses all of the business and non functional requirements. If you need to change the business model for any reason, make sure that by changing the model, you are still meeting all of the original business requirements. In other words, the only reason to change the business model is to address any ambiguity. However, if your changed model is in a way a superset of the originally provided model, it should be okay. For example, if the provided model allows you to have one credit card per customer and you change it so that a customer can have multiple credit cards, you are not really breaking any requirement. You are only making the system more flexible. However, changing the core business object relationship itself just to make architecture easier is a big no IMHO.

SCEA 5, SCJD,SCWCD,SCJP,PMP,IBM-SOA Solution designer,IBM-XML
deepak adlakha
Ranch Hand

Joined: Jul 27, 2001
Posts: 325
Argeed. All requirements needs to be addressed that's the bottom line and in reality we can always go back to Business Analyst and ask for clarification, but in part 2 there is no one to clarify, so we have to make assumptions and move forward keeping in mind the original requirements.

Girish,

You may want to look at this too

http://www.coderanch.com/t/418974/java-Architect-SCEA/certification/Dreamcar-Assgnment-Part-II-Business
sivan jai
Ranch Hand

Joined: Feb 24, 2010
Posts: 115
My suggestion would be to treat the given business model sacroscant - I found myself in the same situation and reisted the temptation to act smart. My reasoning was I didnt want to explain the change I'm making and bring unneccessary focus onto an area.
As for the sequence diagram if you think there is a clear typo - for example an actor is used in a use case who is clearly out of place there just assume it was a typo and move on. This is what I did for one of my use case.
deepak adlakha
Ranch Hand

Joined: Jul 27, 2001
Posts: 325
So Sivan, are you proposing, even if something is not clear in BDM, dont change it and change your design to work as per BDM ?.

Because i reread the assignment many times and its not mentioned anywhere about request or part requests which Girish asked in original post. It's just that BDM model which is creating confusion for this.
sivan jai
Ranch Hand

Joined: Feb 24, 2010
Posts: 115
Yes - keep the cardinality as it is given in the business model even if you think it makes more sense if it is changed to 1 to many from many to many things like that. If you read chapter 9 this very thing is discussed.
Once you have decided on keeping the relationships as given ie. unchangeable - you will usually find a way by which you can justify the relationship.
ofcourse the above is from my experience and very much subjective.
Girish Mohite
Greenhorn

Joined: Jan 29, 2009
Posts: 13
Thank you very much for your feedback guys.I will try keeping the model same and come up with a design that supports it.
However in few cases the cardinality isnt defined like if a request has more than one part,what do we do in this case?
sivan jai
Ranch Hand

Joined: Feb 24, 2010
Posts: 115
In those cases you are free to use the relationship that you deem fit but make sure it is really not given - for example in my diagram the * was so near to the line at one place it was not even visible at first glance - only when zoomed I was able to find it. So the slogan is "maintain whatever is shown and come up with new ones where not shown"
Kuppusamy Venkatasubramanian
Ranch Hand

Joined: Dec 30, 2004
Posts: 91
Hi,

Aren't we discussing too much details about part2?

Cheers..


SCJP1.4, SCBCD 1.3, SCWCD 1.4, SCEA 5, JLPT-N3
My Blog
Teja Saab
Rancher

Joined: Mar 08, 2010
Posts: 152
Kuppusamy Venkatasubramanian wrote:Hi,

Aren't we discussing too much details about part2?

Cheers..



I think that it is permissible to talk about part 2 in abstract terms. Of course, we cannot talk about any specifics pertaining to any assignment.
For example, it is okay to talk about how we can integrate two businesses using JMS since it can be a generic discussion, but we cannot talk about it directly in the context of the assignment by using terms/requirements that can be directly correlated to the assignment.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11508
    
  95

Thanks Kuppusamy and Teja for considering this issue.

The general rule we have used in the past is that questions trying to understand the domain model are ok, as are generic questions (which tools to use, who to contact, how to package). As long as the talk stays generic we are happy.

Teja gives a great example: talking about how we can connect two services using JMS works as long as it stays generic (and has the added benefit that it may be of use to part 1 candidates). Talking about whether to join the Foo system with the Bar system using JMS is not allowed as it is very specific to the FooBar system and provides part of a solution.


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Business Model