• 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

Questions about Part2

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I've just received my project about an Oil Company (I'll try to be vague as possible) and have a few questions.

I've looked through the domain model the use cases but it just doesn't seem right to me. I would have to 'correct' the use case and domain model but I'm not sure its open to interpretation.

One actor in the use case specifically mentions an employee. But there is also an actor called 'Buyer'. The way I've interpreted the problem is the employee is the Buyer in my system.

The other interpretation is a massive duplication of effort with an external system (apologies if this is too much).

My solution doesn't seem very complicated. I alway try to simplify solutions in real life but I wonder if I'm missing the point of the exercise.

The domain model has items that I don't think are relevant.
Should I take the use case literally 100% (I know in real life I would go back to the customer).
The use case specs examples seem to be worded that my system would do what the external system did as well.

I guess what I'm asking is are these sections to be taken with a 'pinch of salt' and then base a load of assumptions of why I think the use cases are over the top?


Once again apologies if I've contravened the rules.

By the way thanks for all the great info - I passed my part1 with flying colours.


Many thanks,

Lovage....
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You are within the rules for talking about the assignment. Congrats on part 1 and welcome to CodeRanch!

I've looked through the domain model the use cases but it just doesn't seem right to me. I would have to 'correct' the use case and domain model but I'm not sure its open to interpretation.


That's a matter of debate. Some people say the are penalties for changing the uses cases. (I suspect this is because it could be oversimplified.) Others say it is fine. Personally, I wouldn't change the use cases unless they contradict each other. I would make assumptions about the details and document all of them.

One actor in the use case specifically mentions an employee. But there is also an actor called 'Buyer'. The way I've interpreted the problem is the employee is the Buyer in my system.


I haven't seen the assignment so I don't know for sure. But couldn't a buyer be external too? Duplication isn't necessarily bad and is something you can design for.

My solution doesn't seem very complicated. I alway try to simplify solutions in real life but I wonder if I'm missing the point of the exercise.


My solution didn't seem complicated either. I think that's because I'm used to complex real world systems. There are some posts in this forum with how many classes/components/etc were in a solution. (See my signature for a blog post containing my metrics.) This should give you a feel for whether your solution is too simple.

The domain model has items that I don't think are relevant.


I only encountered one odd element in my domain model and assumed it was important.

Should I take the use case literally 100% (I know in real life I would go back to the customer).


Not 100%, but not 50% either . And yes, you should document all assumptions. One thing I did on mine was write that I assumed I asked the customer to improve the use cases in certain ways and he said no. That way I showed my analysis skills in noticing things that could be better without changing the spirit of the assignment.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic