• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Business Model

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 325
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 325
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?
 
Rancher
Posts: 152
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
deepak adlakha
Ranch Hand
Posts: 325
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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

https://coderanch.com/t/418974/java-Architect-SCEA/certification/Dreamcar-Assgnment-Part-II-Business
 
Ranch Hand
Posts: 115
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 325
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 115
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 115
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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"
 
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Aren't we discussing too much details about part2?

Cheers..

 
Teja Saab
Rancher
Posts: 152
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Now I am super curious what sports would be like if we allowed drugs and tiny ads.
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic