CODEWITHSUNDEEP
javaclassumlclass-diagram
moovon
moovon

Reputation: 2359

Should Service Class be part of the class diagram?

Let's say, we want to build some system like Ticket Booking (ticket booking is not the key thing here, it's just an example)

So we have a User class, Ticket class etc

We also have a TicketService class which provides methods for bookTicket() cancelTicket() etc etc

In the class diagram, TicketService should be included or not?

If not, where should the bookTicket() or cancelTicket() be shown on the class diagram, in the Ticket class or the User class(since user creates the ticket)

Upvotes: 2

Views: 935

Answers (2)

Shimada_R.
Shimada_R.

Reputation: 1

You should if you are modeling your software as close as possible to the implementation (usually on the later stages of the modeling process).

On the early stages (analysis model) you should focus on modeling the domain classes and their relationships and with only the essential attributes and methods of the classes (that is, what are their responsibilities, the what of the system, this can include the essential of the boundary classes, controllers and model entities). On the later stages (project model), you should focus on the how, that is, further detail the domain classes to how they would be really implemented and executed, this can involve splitting a class in two or more other classes.

Of course all this "stages" talk is not hard science nor mandatory. Usually both stages are mangled together or traces of the latter one can show up on the early stage.

Upvotes: 0

muszeo
muszeo

Reputation: 2352

This depends on what you want to represent. If you are wanting a faithful representation of your code in a Class Diagram then yes; if you are simply wanting to explain the logic of your business domain (i.e. the business entities in the domain) and you don't want the clutter then no you could drop the service class. This is subjective/opinion based and depends on what you need to do.

If you want to avoid the service class but you want to represent the logic of the domain with behaviour, then you could simply add a "book ()" and "cancel ()" operation to the Ticket class. This would be the standard approach in object orientation -- i.e. encapsulation of behaviour (and data) within the object that is responsible for it.

Upvotes: 5

Related Questions