If you "almost" have ended your design and you find out that one or two classes (from the original DBM) are just left overs - no one reads or writes from them, no use case mentions their concept, etc. As a last resource you can fabricate a requisite to use those classes or, it's better to just leave them alone in the corner ?
pablo, they're connected in the bdm, but no use case "touches" it. A contrived (afaik, not from any assignment) equivalent situation: you have a grocery store sales receipt with the n candy items that were sold on it. Then the uses cases only use the receipt itself. Ok, if you had a "sales" use case you know that you have to group the items under a receipt - but I don't.
A bit off topic. Sorry. How do you differentiate b/w association vs aggregation and association vs composition?
Hi, the association is a line with an optional arrows at every end (if the navigation is bidirectional you will not see any arrow), the aggregation is a line (just like association) but with an diamond at the beginning, and composition is the same as aggregation but with a fill diamond.
now, the differences are:
Association: two classes are related by a variable in the class members Aggregation: one of the classes has a collection of another class but if the collection is empty the class is still valid Composition: on of the classes has a collection of another class but if the collection is empty the parent class is meaningless.
Association: a Person have a Dog Aggregation: a Person have pets (more than 1)... if the person does not have pets is still a valid person Composition: a Company have employees (more than 1), if the company does not have employees is not a valid company... or a Book as Pages, if the Book does not have any pages is still a book?
I hope this clarify the concepts... if that were you looking for.
Originally posted by Ahmed Mahdi: pablo, they're connected in the bdm, but no use case "touches" it. A contrived (afaik, not from any assignment) equivalent situation: you have a grocery store sales receipt with the n candy items that were sold on it. Then the uses cases only use the receipt itself. Ok, if you had a "sales" use case you know that you have to group the items under a receipt - but I don't.
Even if they are not touched in the use cases the classes will have relationships with other classes right?, for example: if you have Company they will not talk about company in the use cases, they will talk about Employees, but an Employee belongs to a Company. (btw, this is not part of any text in the assignment, is just to clarify)
If they are connected in the bdm I thing they will be connected in the class diagram, maybe through another class (a bridge class)
Guess the standard OO rule-of-thumb applies: if the classes doesn't have any specialized behavior there's no need to separate them, if they DO have different behavior, they should be different classes... Also, I agree that if the class doesn't participate in any collaboration, why it should be in the system?
I think I've got the same problem in my task, and I think It is some error in requirements - some missing use case, or something. But maybe I'm wrong . I'm spending really a lot of time on this issue, read requirements thousands of times, but don't have an idea what to do with it