draw UML class diagram with Service classes

0
votes

this is a small scenario of a big system. i want to model this scenario in class diagram and then implement it in code

this is a scenario in book store.there is customer and books customer can buy books,search books by name,and read books

class diagram implemented in following ways

1.put all operations to the customer class because customer is the one who perform these actions but buyBooks(),searchBook(),readBooks() methods are not responsible for changing the state of customer class (these methods are not working on data inside of customer class ) there for it violate basic oop principle encapsulation.

customer can buy,search,read 1 or more books therefore association marked as shown in image.

i have found lots of class diagrams draw this way when referring the INTERNET

enter image description here

2. put all operations to the customer class same as above. and mark each associations seperately, with three separate lines

associations

  • customer can buy one or more books
  • customer can search one or more books
  • customer can read one or more books

enter image description here

3.in here put all operations to the service class because those methods are not responsible for changing state of neither customer,book class

and then mark association.

enter image description here - among theses which one is correct class diagram ?
- is it acceptable to draw service classes in uml class diagrams ?

1
oopumlbehaviorooad
You describe your implementation, but not your requirements. But the latter is what drives the design. – qwerty_so

1 Answers

3
votes

Either the first or the last diagram can work in my opinion (once corrected), but I lean towards the first implementation. The second one is just plain wrong.

I would use the first because a "Customer" implies a person whose exclusive purpose in the system is to interact with your Book class, especially in light of the fact that your multiplicity values indicate that a customer must associate with at least one book class. If a customer did more things than interact with books, it might be useful to abstract the things that a customer does with respect to books into a service, but I don't see the need here.

Now, your class diagram syntax is off. The arrows should be open (like >) rather than solid. Also, your multiplicity value on the Book class seems wrong: a book instance will presumably have zero customers associated with it if it hasn't been bought yet, and one customer associated with it if it has. If so, your multiplicity value on the book end should be 0..1.

Finally, your second diagram is wrong because associations are by class rather than by operation; you don't put an association for each operation, but one per class.