How to make a class diagram out of a use case diagram?

I plan to do a system aiming at journalists submitting news stories to editors in view of publishing. This is my use-case diagram:

I struggle somewhat to define the classes based on this diagram. Below is how I've defined key classes so far, using actors and some of the use cases. But I am not sure if this is the right approach.

How do I make a class diagram out of the use case diagram?

Story

Attributes:
  storyID
  title
  content
  status (e.g., submitted, approved, rejected, archived)
  submissionDate

Methods:
  getStoryID()
  getTitle()
  getContent()
  getStatus()
  setStatus(status)

Journalist

Attributes:
  journalistID
  name
  email

Methods:
  submitStory(storyDetails)
  getJournalistID()
  getName()
  getEmail()

Editor

Attributes:
  editorID
  name

Methods:
  reviewStory(story)
  approveStory(story)
  rejectStory(story)

FileVerification

Attributes:
  verificationStatus

Methods:
  verifyFile(story)
  

ProcessingCenter

Methods:
  processApprovedStory(story)

System Class

Methods:
  validateInput(input)
  storeData(data)
  generateNotification(recipient, message)
  sendNotification(notification)

Your question is interesting as it highlights some typical misconception about use-cases and their relation to class diagrams. My answer may not be what you expect but I hope it will nevertheless help you.

Getting to the class diagram

The only objective and systematic way to transform a use-case into a class diagram is the Entity-Boundary-Control approach.

While this approach helps to get classes for the use-cases themselves (Control), and the association with actors (Boundary) in a straightforward way, it still needs domain analysis to find out the domain classes (Entity). Looking at the candidate classes you have identified, you seem more interested in the latter.

Your use-case diagram offers little insights into the domain. The best source is therefore the original requirements, as well as critical thinking about how the classes may be related to each other. With the information available we cannot help more.

If you have further questions about the class diagram (separate question, not an edit of this one), please focus it on a specific doubt, as we don't do general diagram reviews here.

The use-case diagram

Formally, the diagram is invalid as it is not allowed to associate one use case to another as you did with Login.

Use-case diagrams shall in no way be used for modeling the flow of events. Even if you add extend or include, the goal should never be to show that one action happens after another.

I strongly recommend that you transform your use-case diagram into an activity diagram. Theses are much better suited to represent command and object flows. And it will also allow you to cross-check the operations needed. Alternatively you may use a sequence diagram to explain the interaction between the user and the system. You can then enrich this sequence diagram with instances of the other involved classes and this is really excellent to systematically engineer the operations needed, as you may deduct them from the messages between the lifelines.

Then keep in your use case diagram only the real use-case, i.e not what the user can do, but why the user want to use the system. I see only two valid ones here:

• Submit a story (main interest for the author)
• Review a story (main interest for the editor)

I could imagine two auxiliary ones:

• Archive story (main interest for the archivist, or accessory interest of the editor, as it may support his/her work)
• Publish a story or Send story for publishing (depending on whether the the publisher or an external publishing system would be the supporting actor involved in the use case)