Very explicit candidate use cases: Book tickets (class and method of Registered user), Make payment (class and method of Registered user) So let's brainstorm a little bit to find everything that looks like an interaction: The classes Movie, Book tickets, Make payment are obviously not representing roles of a user.Ī use case defines the interactions of a system and an actor in order to achieve some goal. Candidates in your diagram are: visitor, admin, and registered user However, by analyzing your specific diagram from a human point of view, you can very well infer a class diagram:Īn actor specifies a role played by a user or any other system that interacts with the subject. In fact, for a given class diagram, it's not even granted that there is a use case at all (for example, if the classes represent only the relation between business objects and no actors). As Thomas pointed out, there is no algorithmic way to go from a class design to a use case.
