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.
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.
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.
in uml - system sequence diagram, can the system ask input from the actor (see attached picture)
In my example, the scenario is: system is prompting a confirmation input from user and user is to enter in the input.
Wondering if this is the correct representation for it? I asked as usually I have done it the other way round, in which actor gives input to the system and system return the output based on input...
Preliminary remark
The practice of showing an actor in an interaction diagram is well accepted and quite common.
Nevertheless, in principle, an UML interaction diagram such as a sequence diagram, should show interactions between lifelines within an enclosing classifier:
The actor being external to your system, it’s not a part of any enclosing classifier in your system.
As a consequence, this is valid UML only if the scope of your model is larger than the IT system, i.e. you model the organisatiin that uses your IT system.
Moreover the message semantic is not clearly defined for human participants, which is exactly the issue behind your question
Be consistent
If you choose to go on with your modeling approach and consider the actor as any other classifier, then your actor instance should behave as any other object.
The flow of messages shows which object is the sender of the message and which object responds. You should consistently keep this logic, as you did in your diagram. It will be btw one of the rare place on your model where you can show that the system is at the origin of this specific interaction and not the user. (hint: don’t forget the execution specification on the lifeline: it’ll increase the readability)
If you would materialize the free-will of the actor by an arrow/message in the opposite direction, you would only increase the ambiguity further: this would give the impression that the actor is at the initiative of the message, and that the actor could send a completely different message instead. And I’m not sure that your system is designed for responding to arbitrary messages from the user.
Another alternative?
A less ambiguous alternative could be to show the interaction between a system core element and an element that represents the UI: the UI element acts as proxy for the user, but since it’s an object like any other, the interpretation of message flows is unambiguous.
This is one of the idea behind the ECB decomposition, the C being a use-case specific controller (so it links this interaction to the requirements) and the B being the UI boundary exposed to a specific kind of actors (without entering into UI details).
Short Answer: Yes
Of course, the context of this interaction cannot be the system, since the actor is outside of the system. However, it is allowed to not model the context and let the interaction be its own context. Or you could introduce a Context Class, that contains the Actor and the system. But these are only formal considerations.
More important is, whether it is useful to do this. I would say, it can be. Describing how an actor will interact with the system is one outcome of analysing the use cases. Many people will use text to describe this, but in complicated cases, UML behavior diagrams, like activity diagrams or sequence diagrams can be used.
I would reconsider using a synchroneous message here, though. Communication with a human actor is by nature asynchroneous. You never know, whether the message arrives, whether the actor understands it and whether the actor responds with the appropriate reply message.
PS: The reply message should show the name of the message it replys to, not some arbitrary text. If you want, you can show the return value after a colon (confirmationInput():Answer)
Confirmation is vague.
As a response to user input this part would be missing in your SD. Being incomplete would not be wrong. In that case you just describe that part which starts from the confirmation.
As part of some system activity (e.g. you have a control process which detects over-heating and asks the user to continue with a shut down or so) that part would not show the start of the use case being likely something like "Observe XY".
In any case using system as life line to the right seems pretty much pointless. One would be interested in which object of the system is asking for confirmation.
The question is always: what does the editor of the diagram want to tell someone else.
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 have a few questions regarding use-case diagram:
If my system has register/login use-case for guest, should it be enabled for admin, user (i just wanna clarify, if i have login system, do i assume that admin, user etc. are people who already logged in to system so i skip them with logging thing)?
If my system has a student actor, that is signing for individual seminars/courses, do i have (or am i allowed) to make use-case for ,,taking class'' after singing for them, and should there be relations between those 2
Should my teacher inherit from student actor, since he can browse courses as well? (and so on admin?)
Is my payment setup correct?
Remember that these are roles not people. An admin can be a guest, so long as they behave entirely like a guess, no special functions or rules. However, during log-in the user role could change, become admin. Note you are in some sense missing authenticate user, each use-case that requires security should include it, generally not extend.
Only if it interacts with the system, example, triggers an auto completion or is tracked in some way there of. Relations are not needed generally, associations could help communicate something that is ambiguous, but I am not sure what the would be in this case.
Nope, really then the role is any user could browse courses once they are authenticated. You could have students, admins, and teachers be sub-types of authenticated or associated person, etc.
Depends. Firstly you never pay and sign-up at the same time, so from a user standpoint that is broken. There are other ways in UML to connect this constraint of paying for courses. Process diagram, state diagram, etc. Because payment is really a long running transaction which can be hard to pin down. I would personally show the student and the external payment system interacting with the "payment" use cases.
Remember unless you are generating code most of the time UML is about communication so knowing your audience. Do not be afraid to use comments or constraints, if this is homework, use a constraint and get some real points. Maybe even put a constraint on the sign and pay course use cases.
If you want the admin to be able to log-in then he would have a use case for that. I agree that he most likely won't be registering, so maybe you want to break the register/log-in into two use cases?
You do not have to make a "Take Class" use case. Only make it, if that's how the user will interact with the system. My guess is that he won't be "taking" the class with the system, in which case it won't be a use case of the system.
I would think that you wouldn't want to inherit from student. First of all, from a realistic stand-point, it doesn't make sense. That would mean a teacher is-a student. You could extract that behavior to another parent class, but that might make the hierarchy too large and confusing.
If you are asking whether it is correct to say "sign for course" includes "pay for course," then maybe, it's probably better to use extend.
Another suggestion. The black arrow (usually means "dependency" in UML) you have between Actors and Use Cases, should probably be bi-directional, non-arrowed, line (this is usually called "association") At least that is what the UML standard says.