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?
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 ?
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?
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.
You may want to look at this too
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.
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.
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.
However in few cases the cardinality isnt defined like if a request has more than one part,what do we do in this case?
Aren't we discussing too much details about part2?
Kuppusamy Venkatasubramanian wrote:Hi,
Aren't we discussing too much details about part2?
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.
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.