The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

"Login" is not a Use Case

In the context of OO analysis and design...

I just realized today that "Login" is not a Use Case you should be writing.

Surprisingly, this was not obvious to me.  It became obvious when I got through making a laundry list of use cases and, upon review, noticed I had left out the login process.

Then I realized, no user *wants* to login. Users want to post messages, change their e-mail address, or cancel their subscription.  Nowhere will you find a user that want to go to you site and "login."  Logging in is just a by-product of other use cases and should be treated as such.

I find this realization important, since many coders (myself included) will begin development thinking functionally: "Hmm. I need a login screen, since we will authenticate our users.  We also need a Users table... some DAOs... Oh, I need some code to generate default passwords..."

The biggest impact of this realization is to other use cases.  I'm not thinking of authentication as just another use case that gets referenced whenever we need to authenticate a user.  Now I see authentication as an (annoying) step in other use cases that should be seamlessly integrated and minimized.

I predict my final product will be much cleaner and user-friendly thanks to this slight perspective change.

Your comment?

This may be blindingly obvious to others (and I'm sure there are a few regulars here who will take the time to point out how obvious this is to them), but I wanted to share it with the JoS readers, anyway.
Caffeinated Send private email
Tuesday, September 21, 2004
"Successful Login" is normally a pre-condition for many use cases... and "Login" would normally have input, output/post conditions, actors, and many other use case things.

I think it IS a Use Case, but it's sort of an assumed one that isn't explicitly asked for by the client.
KC Send private email
Tuesday, September 21, 2004
"Login" doesn't really fit well as a use case. Whether it is -- for lack of a better term -- a first-class operation of your system depends on what you're doing. If users can do some things without logging in but must log in to perform certain tasks, then logging in is best seen as a side-effect of the task the user is trying to perform.

Many web-based systems fit this model. We allow their users to work their way through the site until they try to do something which the general public isn't allowed to do. Then we ask them to log in and, once they have done so, return them to what they were trying to do. On systems which require users to authenticate before doing *anything*, it makes more sense for the login screen to be the system's entry point.

In neither case would I characterize logging in as a use case. My clients *never* talk about the authentication system. At most a client must specify that the system "must be secure". The specifics are an implementation detail that users don't really care about as long as it works and isn't too obtrusive.
comp.lang.c refugee
Wednesday, September 22, 2004
"[Login] in is just a by-product of other use cases and should be treated as such."

"Now I see authentication as an (annoying) step in other use cases that should be seamlessly integrated and minimized."

"a side-effect of the task the user is trying to perform"

'that the system "must be secure". The specifics are an implementation detail'


You both seem to make the one big mistake for which security experts always give red alert warnings: treating security as a by-product or an add-on that can be attached later. It won't work too often. Security must be there by deeply embedded design inside the whole system right from the start, or it may fail, endangering your whole system integrity.

Especially a login is very important - just imagine a hacker posting illegal content under another user's login, imagine a hacker deleting the database under an administrator's account.

Of course, the security expert's demands are on the other side of the fence as the things users really want to do. A system with which the users are really happy is totally unsecure, a totally secure system is practically unusable. The programmer is balancing on the fence, trying to find a more or less annoying compromise between both sides.

Login is not a use case - it is an integral part of the whole security as a basic system design decision.
Wednesday, September 22, 2004
"I think it IS a Use Case, but it's sort of an assumed one that isn't explicitly asked for by the client."

I'd say Caffeinated is right, it is not a use case.
And clients don't ask for it explicitly, although many will, because it is not on their list of goals they want to achieve.
It is really a solution to fit one or more of the requirements most clients have about achieving their goal. Usually identification and authentication for the purpose of security or privacy.

The test is, would your clients goals be met any less if you choose a different technique, say a retina scan?

Of course the current thinking on use cases with includes and uses or whatever they are called these days, make things a bit fuzzy.

I have stopped speaking of use cases all together and speak of goals users want to achieve and scenarios that illustrate their activities of achieving those goals.
The intent is the same as the original intent of use cases.

I have found that Caffeinateds realisation is a major step towards a better understanding of what users need and what you can do to give it to them, time, money and technology allowing.
Practical Geezer
Wednesday, September 22, 2004
There seem to be 2 schools of thought here:
1> the use case as a stimulus/response model, paritioning the modeled system into inside/outside parts
2> the use case as a model of naked "business value" positions, separating out the primary goal interactions of the system from its decorations.

Both have their place, butI still think the UML stickmen diagrams are an offence to anyone with an ounce of feeling for aestetics, right up there with the grey/brown metal filing cabinets and the fluorescent overhead lighting
Just me (Sir to you) Send private email
Wednesday, September 22, 2004
A Use Case is not supposed to describe a method... just pre/post-conditions, so it doesn't matter whether it's fingerprint, password, retina, or a key fob.
KC Send private email
Wednesday, September 22, 2004

Users are not Use Cases.

However all Actors, who may or may not be users, need to identify themselves (in non trivial applications), therefore there is the Use Case of the Identified Actor.  To assume that all entrances to a system have been catered for is an assumption too far.

So, even if you think Identifying successfully, or Logging in or whatever isn't something an Actor does you still have to present that and anchor it to something.

Users are not Use Cases.

Sometimes the System has a Use Case that no Actor has a use for but which the System cannot continue without fulfilling.
Simon Lucy Send private email
Wednesday, September 22, 2004
"Sometimes the System has a Use Case that no Actor has a use for but which the System cannot continue without fulfilling."

Which is where I think the terminology gets confusing and why I stear clear of it. When communicating with users that is.
I would have preferred the term use case to be reserved exclusively for defining the behaviour involved in achieving a users goal. And have a different term altogether for grouping repeated or optional behaviour. Simply to keep the distinction clear between what a user needs from the system and what developers choose to organise their description of the system.
Practical Geezer
Wednesday, September 22, 2004
Thanks for the replies.

To elaborate on my position (I've been further refining some of my use cases)...

I've decided not to have a specific use case for Login, such as:
 Main Flow:
 - User enters username/pwd.
 - System checks username/pwd.
 Alt Flow:
 - User enters invalid username/pwd.
 - System returns error
 (Blah, blah, blah)

Why, you ask?  Simple, because I've integrated the login process into each use case, thereby refining and improving each individual use case.

Put another way, I've realized that website users should almost never need to look for and use a login link. (I don't believe Amazon even has a login link. Let me know if you find one.)  The login process should be specifically integrated into other processes where and when appropriate.

For example, if posting a message to a discussion board requires authentication, then you should be prompted to login when the Post Message link is clicked. Not, "you must login to *see* a Post Message link."

I know this is a bit subtle, and that may explain why it escaped me, but I feel it is an important distinction.  When you have a canned login process you tend to not think about how it *smoothly* integrates into other workflows.
Caffeinated Send private email
Wednesday, September 22, 2004
Another point, does a developer *really* need a use case to describe how a login process works?

What we need is screen shots and workflows.
Caffeinated Send private email
Wednesday, September 22, 2004
Login is an use case. It usually belongs to the authentication subsystem (part of security) and typically attaches to non-business functional requirements.

You may think this is trivial but it is not. Different actors are authenticated (login) differently:
- a human user is usually required to provide a simple credential (username password challenge). In a single access point login more info may be required (which realm/system you want to access) or in a high security environment who knows what else they have to do (swipe a card, scan a finger print, ???). Even with the simple login, do you want to have automatic login based on, say, trusted a trusted host list?

- an automated system login will be required to provide different type of credentials (verifiable electronic signatures, certificate providers)


Authentication is not trivial and you have to describe what you are trying to achieve. Do that with a use case.
Friday, September 24, 2004
Rather than repeat, I'll point to a thread I started on this site under "Social Interface Design" headed "Stakeholder Interests." You can't just look at Use Cases to satisfy user goals, you have to take into account the interests of all stakeholders in the system. And the functional bias of use cases often diverts attention from these other interests.

Security is an interest of many stakeholders, and each stakeholder will probably have a different consideration. For example, a customer may be concerned about receiving unsolicited junk e-mail, or their credit card being obtained by a thief. The company probably has an interest in preventing their competitors from getting access to their customer list, keeping customers, but trying to make some money on the side by selling all or part of the list to other companies. Good system design will balance these various interests; it will never ignore them or push them into the background.

Logon is a use case. The goal of the user is to gain (legitimate) access to the resources of the system. As many writers have pointed out, there are different levels of use cases; I typically consider this to be a system use case, since it is very much tied to implementation.

How this use case will be initiated is the biggest problem. If the user always logs in as the first operation, it fits the normal model. If the system prompts for a login only when some restricted material is requested, then this reverses the normal viewpoint of a use case; the system is the primary actor (initiator), and the system user is a secondary actor. Also, the programmer wants this to be auto-magically initiated without messing up the code for the high-level use cases.

You should write this use case at some point; that way your user documentation and you source code should match. Also, you should be able to cross reference your use cases to the rest of your requirements, to show how they cover all your stakeholders' interests.

Sorry, no easy, happy answers here. Software design just IS complex. Probably best to say this is one of those times when a technique (here, Use Cases) isn't always the best answer, use it where it works well, and use whatever does work the rest of the time. Trying to make a something work well in all situations just makes it too complex and cumbersome to remain useful.

P.S. Amazon does have a login prompt. (a) when you first visit their site and it sees if you have a cookie, (b) at the top right of the web pages, you are invited to login, and (c) when you go to check out your shopping cart, you can finally login and use a saved shipping and payment profile.
Dave Lathrop Send private email
Monday, September 27, 2004
Absolutely agree with the OP. Login is not a use case. Login is not (usually) a requirement, but a solution to some other requirement. The requirement may be something like "ensure no unauthorized users make use of the system", or "keep a record of what actions each user performs". The solution may be "make users log on, so we can identify them". But note - login is a solution to a requirement, not a requirement in itself; so it has no place in a use-case (it has a place in a use-case realization, of course).
Breandán Dalton
Thursday, September 30, 2004

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz