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?
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.
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.
Related
I have a flow of events and alternative events for a Login use case.
Basic Flow:
The actor enters his/her name and password.
The system validates the entered name and password and logs the actor into the system.
Alternative Flows:
Invalid Name/Password: If, in the Basic Flow, the actor enters an invalid name and/or password, the system displays an error message. The actor can choose to either return to the beginning of the Basic Flow or cancel the login, at which point the use case ends.
I come up with this diagram:
I was said that there is no need for an intermediate Login Screen life line. How should I design the diagram now, according to conditions given above?
This diagram is not bad. It is however somewhat confusing, because:
Login is not really a use-case, even if it's a popular practice. This has however no impact on your SD diagram itself.
Showing actors in a sequence diagram is not formally correct, even if it's a popular practice.
Login Screen is in fact a part of System, which creates a kind of implicit redundancy.
Don't worry about too much about the two first points, if this is the kind of practices that your teacher showed you.
The last point could easily be addressed:
The last lifeline could be more specific about the internals (example here), or,
Keep only two lifelines, one for the actor and one for the system. THis is in my view the better alternative when you use actors in a SD.
Imagine that you have a simplistic GUI application. When you open it, there is an input box and a button placed on the application window. When you press the button you should see the entered value displayed in a popup message box. Of course, the button can be clicked without entering the value into the input box. Another possibility is that user exits the application right after opening it.
How-do you model this in UML activity diagram?
The typical UML elements like
a) decision node
b) fork/join node
do not seem appropriate to me.
According to my understanding a) is used when a check on certain set property is made and according to the outcome, the flow is routed somewhere; this is not appropriate since no checks are made
b) is not appropriate since it assumes parallel execution (?) which is not the case in the modeled situation.
There is a similar question here on SO though I don't understand what is meant by the suggested "Event element" in the accepted answer.
This seems not appropriate for a useful activity diagram:
Of course, the button can be clicked without entering the value into the input box.
Then there was no noteworthy activity, so nothing to model.
Another possibility is that user exits the application right after opening it.
Same here.
Most aspects of UML are rather GUI-unaware. You want to not spend your time modeling trivial cases but instead focus on actual workflows. Such diagrams will add way more value.
Nevertheless if you were to model something for your example, your assumption is basically right. The input validation is not bound to the willing user decision of leaving an input blank, though. You gotta do it anyway.
It is possible.
Use call operation for operation invocation on classes instance which represent GUI elements and also use Accpet Event Actions to receive events from GUI elements.GUI elements should be defined as standard classes. See Action Model part in UML Superstructure document. UML Website
It's a very interesting question. As already said in the previous post, a UI typically receive events and send informations in a visual form.
So, the particular UML actions (activity diagram) like "accept event" and "signal sending" are appropriate when the UI can receive different s events in no predefine order. Activity diagram are generally based on a "scenario" point of view, showing some scenarios but not all. Make events oriented activity diagram is more difficult; sometimes, "interruption region" have to be used.
I'm trying to write an use for shopping online . Customer can search for their desired item and add them to the shopping cart,but when they decide to check out, they need to log in with their account. But what happen if customer already logged in ? Is my diagram still correct ? If not, How can I modify it ?
Any use case must be connected to some actor(s). So, you should add connections.
The CheckOut use case is strange and inunderstandable. I don't know any action in net stores, that includes both login and payment. If you mean ordering, the login or payment are additional separate use cases, that are connected to ordering by some conditions that could be described as states.
Don't forget, you can't show sequences of actions and states by use cases elements only. If you have a small use case diagram, you could include state machine diagrams in it, but here it is not good - You have totally forgotten the admin and seller actors and their use cases, so the full use case diagram will be too large to add something extra in it. Describe sequences about logging in additional State Machine diagrams.
You are trying to use the use case diagram as a workflow editor, which is incorrect.
Use case diagrams are used to indicate the actions that a user can take to accomplish something. They do not represent the sequence of these actions. Each use case starts from a specific user action, and not as a side effect of another use case.
In your diagram, the "Search" use case is fine, but the display of the result is part of that use case. It would not be very useful if the system would just display a "search complete" result and then force the user to do some action to view the result... Although you have an <<include>> relationship, that it not what it means.
One example for <<include>> is one for a Login use case. The Customer could login on their own before doing anything else or the login could be triggered by another use case, such as Check Out. Login would therefore be a use case on its own and it would also be <<include>> by the Check Out use case.
Add to Cart is a use case that should be triggered directly by the Customer. It is not something that is triggered automatically - the Customer needs to do something.
The same applies to the Make Payment use case. I would think that the Customer needs to perform an explicit action in order to pay.
Suppose we have a simple on-line store. Things that the user would want to achieve with the store would be:
Register (to create an account)
Browse items
Add items to basket
Checkout and pay
View account information
Edit account information
etc
However, there would be functionality that the user could initiate but wouldn't be their main goal of using the system:
Login
Logout
Select 'electronics' department
Select 'vehicles' department
Enter delivery details
etc
I would argue that things like login and logout shouldn't be in the UML use case diagram. The reason being that a user would not want to go to the on-line store just to login; they would always have another aim which would be to view / edit account information or browse and buy stuff.
Likewise, the two select 'statements' are part of the browse items use case. I wouldn't use generalisation because there could be many departments.
Finally, the enter delivery details is part of the 'checkout' or 'edit account information' use case. I would normally lump this in with the 'edit account information' use case otherwise you may as well have use cases for 'edit name', 'edit email' etc.
My main concern is if you have a very complex use case diagram it defeats the purpose of having one as it won't be easy to read.
So, my question is as follows. Is my thinking behind this correct? Is it best to only model 'real' goals in the use case diagrams or everything that the actors can initiate?
Does a UML use can show everything the actor can do (functionality) or
everything the actor wants to do (goals)?
It can be either - the UML spec isn't prescriptive on that front. Alistair Cockburn created a categorisation for Use Cases that indicates what level they focus on.
Having said that:
My main concern is if you have a very complex use case diagram it
defeats the purpose of having one as it won't be easy to read.
That's a very real risk. Personally I find I get most from UCs by focusing on the users and their goals. What value are they looking to get from the system?
Keeping it at that level prevents a "can't see the wood for the trees" situation - and also stops UCs becoming a complete, functional decomposition design.
hth.
It is not wrong to exclude some use cases from your diagram, and indeed it might be a good idea. For instance, if you are going to show your diagram to the business department, you can draw an UML model that describes the operational use cases. If you are going to hand down your diagram to the programmers, you would want to give them a complete description of what they have to implement. These are just models of your system.
When one draws a use case diagram, usually one also writes the behavior of each use case (as free-text description, pseudocode, or by using interaction diagrams).
The UML specification says that:
A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.
Login and Logout are observable to the user. While the user will not visit your site with the only goal of logging in, such use case certainly has some execution flow that you also want to describe. If you don't allow users to initiate a login by themselves, there will be use cases that include the functionality of login. A user may have also interest on logging out before leaving the site, so that no session data will remain stored in his computer.
Select 'electronics' department, Select 'vehicles' department... Why not just Select department (I suppose that they are not too different).
I would draw this and other use cases, as long as they are relevant to the model.
I want to do a state diagram to represent a user logging in. As far as I understand things, it could be done from two points of view:
Object: States
User: Logged in, Not logged in (perhaps Initialized and Destroyed too).
System: Waiting for login, Verifying login, Error, Logged in.
Does this appear correct? Also, are multiple state diagrams like this really necessary?
"Necessary" depends on what aspect you are trying to document, but I would say no.
If you are in a specification phase (use case elaboration), I usually advise not to use state charts at all; I find that activities are better suited for this purpose. State charts, in my view, are better suited for design descriptions.
This is because activities focus on the flow itself and thus describe something from an external point of view, whereas state charts describe an internal flow in which some defined entity moves between different states.
When you do a state chart you must answer the questions "what is the thing that has a state?" and "what does each state mean to the thing?" (Replace 'thing' with 'part of the system' if you prefer.)
In your case, I would suggest that it is the user (strictly speaking, the user account) that has the state, not the system.
It's not clear from the question what the scenario is, but if we're talking about a typical OS user account, it should probably have states like Logged Out, Logged In, Expired and Locked.
If you do specifically want to model the system side as well, then you should probably break it down to a smaller part, such as a User Client (or Terminal, or whatever). In keeping with the above, the key question is "does the (whole) system behave differently when a user is logged in?" and presumably it doesn't. The User Client, rather than the whole system, would then have states you list.
But all else being equal, I would say that a state chart describing the login/logout cycle should focus on the user account.