2

i am confused in whether how a use case and a class diagram are reated? what i mean to ask is if i have a use case diagram how can i convert it into the class diagram or vice versa.

and also the above question.

I.m.o. the actor should be the name of the class with its respective attributes. but i am still confused as in how to frame the correct and appropriate answer.

a.sin
  • 21
  • 1

2 Answers2

1

The actor in the use-case is external to the system. The classes are internal to the system. So in principle, you don't represent an actor in a class diagram:

  • If you want to have a class that represents an actor within the system (e.g. a player class to manage the player's state whereas the player appears to be an actor), use an ordinary class.

  • If you want to represent the user interface that transmits information from/to an actor, you'd represent a «Boundary» class. It corresponds to the association between an actor and a use-case.

  • If really you want to show an actor class in a class diagram, and none of the previous techniques would appear to be better suited, then you could consider representing it in a class shape, with the keyword «actor» above its name.

Christophe
  • 68,716
  • 7
  • 72
  • 138
0

In UML, "use cases" captures requirements (problem) and "class diagram" captures implementation details(solution). Actors are roles who interact with the system you are implementing.

For instance, let's consider the following requirements for a drone delivery system:

DroneDelvry, Inc. is starting a drone delivery service. The company manages a fleet of drone aircraft.

  • users can request a drone to pick up items for delivery.
  • When a customer schedules a pickup, a backend system assigns a drone and sends the user an estimated delivery time.
  • While the delivery is in progress, the customer can track the drone's location, with a continuously updated ETA(Expected Time of Arrival).

Some of the use cases for the "customer" are:

  • manage customers accounts (register, update etc.)
  • handle delivery(pickup, notifications, etc.)
  • track delivery status
  • manage deliveries history (for a customer) Here the "customer" is the Actor

Some of the classes can be defined based on these use cases:  

  • customer (captures "customer" related details like address, registration details etc.)
  • deliveryPickup (delivery pickup request)
  • deliveryActive (active deliveries)
  • deliveryHistory (deliveries history)
  • deliveryPackage (delivery Package details)
  • deliveryNotify (notify delivery status to the customer)

In this case, the actor "customer" is used as a class name in the class diagram. 

Also attributes and methods can be added to these classes. For example:

deliveryPickup

  • pickup //pickup request
  • status //pickup done or not

deliveryActive

  • pickupDateTime
  • status //delivered or not
balaji balu
  • 7
  • 2