[TriggaMike]

Hey guys, we have recently been introduced to use case diagrams, and I don't know if it's just a combination of poor teaching, poor course resource, or a brutally bad textbook, but these things seem very... useless

I'm just wondering what the general opinion is on them, and maybe if someone had a good tutorial on them if I'm completely wrong here so I can see what they're good for.

Thanks guys.

[OliveOyl3471]

I'm not a professional so I can't say if they're ever actually used, but I don't see a use for them.

[KYA]

They're as useful as JUnit testing or other planned out modular testing methods. You might have inadvertently used them already, example:

Say your writing a bank program. When you deposit $5000 you expect X amount of interest based on the requirements and your implementation. You then test it. This is essentially a use case. You didn't draw a diagram, but you had a hypothesis and you tested it with your software.

Generally though, use case deals with outside influences on your system (like the user in the above), but for large scale "enterprise" systems. Walking through a diagram can assist in planning and bug tracking.

This post has been edited by KYA: 01 October 2009 - 09:52 AM

[TriggaMike]

The kind of things we have been expected to do with them are really vague and kind of annoying. Like we had to just do a general use case for some computer based (theoretical) security system. It had a whole bunch of cases and stupid things and it was really poorly defined. I don't know, the whole basis seems really simple but the standard definition for it seems overly confusing.

I like what you said though KYA, kinda makes things more relevant to when I would actually use it, not this stupid theoretical BS. You should be a prof some day

[Amadeus]

When you design and develop enterprise grade programs, you'll find that use cases (or equivalents) are expected...often in the hundreds. The other is test cases. The QA teams in most organizations are expected to document each of the (potentially) thousands of tex=st cases/scripts, review them with the dev teams and business sponsors, and get them signed off before ever running a test - same with use cases on the development side. Many people don;t realize that there is far more documentation than actual programming in the real world - of course, in a well run organization, they'll give you a business analyst or tech writer to do the actual documentation It's a swell life

[TriggaMike]

Yeah that's what I thought, it's one of those things specifically designed to be a bitch. So really then I get the impression this is more based on what company you're working for, what their standards are, and who is breathing down your neck more or less?

It's times like this that I'm glad I don't plan to work for other people for too long... *sigh*

EDIT: has anyone else noticed that on the home page it has the wrong date/time for when this thread was started? Should I PM Skyhawk or is this a known glitch?

This post has been edited by TriggaMike: 01 October 2009 - 05:22 PM

[ladyinblack]

Yeah, the time is according to probably SH's country, don't know. Therefore its different for everyone, in different country/states.

Use cases are relevant depending on the career you choose, if you intend on being an analyst or tester or something other than programmer/developer, then this is probably where you would use use cases, have team/project meetings and brainstorming ideas.

However, if you planning on becoming a developer in your near future, study life sucks, you gotta study some things that makes no sense to get the degree to get the career you want.

I remember doing them maybe some three years ago, I actually enjoyed them and surprisingly passed the exam with not much difficulty. That was because the examiner, or whomever set out the paper, made it as easy as the exact similar layout or problems from the assignment. Maybe you need a good book. The book I used I think was titled Systems analysis and design, can't remember the authors right now.

[baavgai]

Diagrams and most other forms of documentation are not generally for the benefit of the developer. Theoretically, I might get some use out of an ERD from time to time, but I'm far more likely to look at what's there as opposed to someone's concept of what's there.

I tend to think of anything done in Visio, Powerpoint, and even Word as "suit fodder." It basically gives people who don't know what you're doing the illusion that they do.

On a cautionary note, the less someone is likely to understand what you're doing, the less real detail you want to give them. I've seen managers get bent over how classes or database tables are named. It's comical yet tragic.

[anirelles]

Amadeus, on 1 Oct, 2009 - 03:26 PM, said:

When you design and develop enterprise grade programs, you'll find that use cases (or equivalents) are expected...often in the

That's the point for me. Uses cases are interesting for big projects where you want to list all of the functionalities. Then you can dispatch them among developers and when the program is done you can check every use case have been implemented and working.
That being said, I've been working professionally for 4 years and I've never seen anybody use them.
I've used them only once during an internship where I had to do some analyze and conception. RUP methodology uses UML diagrams intensely.

This post has been edited by anirelles: 02 October 2009 - 04:44 AM

[Aeternalis]

Our systems can be quite complex, so we use them as part of our requirements documentation to define how the users /actors interact with the system. Combine them with other diagrams and requirements documents and you can develop a complete, well documented picture of what the system does and how people interact with it.

The more complex the system, the more valuable the documentation is.

Aet

[Mangotastic]

One of the issues with learning software design techniques in school is that they just don't show the scale what-so-ever. Whilst a lot of the diagrams and design techniques may seem a little pointless on small scale projects they become necessary on large-scale enterprise-sized software development projects.

I've used use case diagrams a lot to explain and document rather complicated points of interaction within the system and to explain the purpose of code that isn't very self-documenting.

The main advantage of a use case diagram for myself is in being able to provide information that doesn't take long to decipher and explains what I'm doing in a decent depth.

[brianarn]

I've not used them much in the process of development, but in doing QA, they were invaluable. A well-written use case documents the expected flow of users through the system, meaning it's very easy to take one and figure out repeatable tests that both follow that flow, as well as repeatable tests that don't, to see what happens when users take potentially unexpected actions (clicking a close window button in the middle of a wizard, etc).

I've also recently been working on a project that started fairly small, but now that we've grown quite a bit, we're going back through and writing up documentation and workflows so that our non-technical users (who have to run administrative aspects of the application) will be able to do their jobs properly, and use cases are a great way to visually represent to less technical people how the software will function and how they should expect users to be interacting with it.

[abudy]

The Unified Modeling Language User Guide
- Grady Booch,
-James Rumbaugh,
-Ivar Jacobson

This book's authors are the UML inventors. The book teachs u how to use these diagrams and all the rules & options associated with the building blocks/shapes. And by the way, I dont like use cases either but as many said, it is used to communicate some complex concepts and implementations without having to spend the rest of your day trying to get the idea through to whom ever it may be. Anyways having UML at your resume is definitely a plus as some enterprise corporations consider them a standard, in all software development projects small or big.

[maffelu]

My experiance is that learning about UML, Use Case, ERD etc was quite dull and I couldn't see the benefits knowing about these things.
This changed when I started working.

UML is vital and Use Cases are used alot as well and it all helps when a project is larger than a calculator app. It's very important if you are, as I am now, taking over a project from someone else. It's not excusable to browse through a 100 files of code to get a view of the project. Having a model over it saves you a lot of time then.

But that's my experience.

[Shukumei]

As a student doing Software Development - Systems Analysis - Is one of my core subjects. To begin with I hated the subject and saw no use for it, personally I think my attitude towards Use Cases was caused by the method it was being taught, however being the good person that I am - I forced myself to start looking at it differently and tried linking what I was learning to my other subjects, I also thought beyond the simple(yet confussing) examples that were used for teaching us about Use Cases - Whenever I had even a mild moment of 'OH I get it' I approched the lecturer and ask if I was on the right track (he is probally sick of me and my questions by now).
Long and short of what I am saying - I now like the subject and I see how the stuff taught in it will be useful.

Also on a bragging note - I am doing extreamly well in Systems Analysis now