How to determine the state in state diagram?

Question

My system has more functions than it is shown inside the diagram but I am trying to do it based on the scenario.

My current scenario is that the librarian/admin is trying to delete a book record from the database, normal users can access the database but they cannot access the "delete book record" function.

The flow shall be like this, the user login to the system, if he/she entered the login detail correctly the account's access level will be checked and granted different levels of access based on the account type. After authenticating the account and its access level there will be several modules of function that can be chosen, such as transaction, search, database, and report module. After the user selects the database module they then choose which record they want to see/modify such as member record and book record. Then they will select the book record they wish to delete among all of the book records that are recorded in tabular form, then will click "delete" to delete the book record, the system will show a confirmation message to ensure that the user didn't accidentally delete the record they didn't mean't to. After the deletion, they can choose to do other actions but I trying to end the scenario so I put logout right after it.

I am actually quite confused about what can be considered as a "state". I know it is somekinds of condition or situation but most of the example I found online give me a feeling that it is an action.

Is the state diagram below being delivered correctly?

Answer 1

First, you have to know what you want to achieve. It seems to me you want to give an overview of the functionality of an application. Then, you decide which kind of diagram best suits this objective. Use Case Diagrams are often used to give a functional overview. Activity Diagrams are often used to depict the flows within a single use case.

If you want to use a State Machine Diagram to give an overview of the functionality of an application, you might consider having one state for every 'screen' (dialog, window, web page, whatever you call it). State X then represents the state of the application in which screen X has focus, i.e. the user currently interacts with screen X. A transition from state X to state Y represents a user action that causes screen Y to appear, while screen X either disappears or looses focus.

For example, the initial state is "Login". The second state is "Main menu". The transition from "Login" to "Main menu" has action "Press OK [user name and password are correct]", which means that the user presses the OK button and the system verifies user name and password.

For non-trivial applications, this may leads to a very complex state transition diagram. In that case, you may either split up the diagram in multiple diagrams, or use a use case diagram instead.

Answer 2

The narrative is about a sequential flow of actions. I've replaced some text with placeholders to demonstrate the point:

the user {action}, if {conditions} (...). After {another action} there will be (...). After {choice} {action} then {another choice} . Then {action} then {another action}, the system will {action}. After (...), {choice} but I trying to end the scenario so I put {action} right after it.

This kind of flow can be easily modelled with an activity diagram.

Your confusion and issues comes from the fact that you try to model the state diagramme based on the action, trying to describe states corresponding to actions to be performed (e.g. Login account) or performed (e.g. Account authenticated) and simply but the actions that lead from the one to the other on the state transition arrows. Your approach is understandable. Unfortunately, it leads to very complex state diagrams, and as qwerty_so explained in the comments, not even valid diagrams.

If you want to go on that way, you need to express states that are unambiguous and not to be confused with an action (e.g. user unidentified, user authenticated, ...), and keep the labels of the state transition extremely short. But a better approach would be to identify less granular states, independently of the activity diagram. Ask yourself what the system shall do when entering into a state, what the system should do while it is in the state, and what it shall do when it leaves this state. If this is unclear, then rethink about whether this is really a good state candidate. Also, think of the state transition more in terms of events that occur, rather than actions performed.