The blog of Tobin

Tobins nerd blog on .NET, Software, Tech and Nice Shiny Gadgets.

Tuesday, November 21, 2006

Use Cases Anyone?...

I've been doing sofware commercially since I graduated in the year 2000, and I've never lost my admiration of Use Cases.

The Sofware Engineering course showed me a lot of doors: UML, MDA, SSADM, DFDs, ERDs, you name it... At one point I remember reading Alistair Cockburns book "Writing Effective Use Cases". It opened my eyes. I thought use cases were little pictures in a UML diagram, and he taught me that there was much more to them than that.

If you've not got into Use Cases, I suggest you take a good look (or a peek, at least).

What they effectively give you is a method for gathering requirements. They encourage you to approach the system from the viewpoint of those people that will interact with your software. They give you a way of organising your requirements in a fashion that suits you - as loose, rigid, simple or detailed as you like. I shouldn't underestimate the word simple there, use cases can be extremely bare-bones (1-2 lines of text) if you wish and still provide much value.

By the end of a very brief use case iteration you should have ring-fenced exactly what capabilities your software will and will not provide. You'll also know every job-role that's gonna be using the solution, what other external systems your interacting with such as ERPs, MS Office Programs, Flat Files, anything non-human basically that plays a part. Finally, if you're willing to leave the technical world you can also elicit what the executives wish to get out of it from a business perspecive (actually, this is crucial IMHO). A brief use case iteration can certainly reveal a lot of things you might not have thought to ask.

This brief iteration might leave you with a use case specification with many many gaping holes. You'll be thinking "I wander what exactly this bit of the software needs to do", Now that you can see these holes you can make sensible decision as to whether the you need to warrant spending more inception time working out the muddy details. After all, hopefully the client is a phone call away... This is a good position to be in.

Despite my like for use cases, I don't come across too many folk in the industry that use them. I'm all for wireframes, site-maps, CRUD matrices and "the software is the specification", but it's weird how so many seem to have missed out.

Is anyone out there using Use Cases? Anyone moved on to better things?

SHAMELESS PLUG - I was considering publishing or selling a variety of example use case documents, which would be based on those that were developed for real projects of budget s ranging from £1K to £50K. The idea being that, if anyone is intersted in learning from real working use cases for real projects, then these would be ideal. If anyone is interested let me know. My plan would be to carefully doctor the real use cases so that they still retain that real feel, but are based on ficticious requirements.

Labels: , ,

.NET 2.0 Got Better with Dynamic Dispatching

Ok, I'm behind the times. Despite using .NET 2.0 on a few small projects, I've not fully got into all the c# language improvements for .NET 2.0 yet.

However, today I was very pleasantly surprised to find that this works...

public void SayIt(String aString)
{
Console.WriteLine("I got a string {0}", aString);
}

public void SayIt(int anInt)
{
Console.WriteLine("I got a interesting int {0}", anInt);
}

public void SayIt(object anObject)
{
Console.WriteLine("I didn't get anything in particular, but it looks like this: {0}", anObject.ToString() );
}

SayIt("Hello"); // outputs "I got a string Hello"
SayIt(2); //outputs "I got an interesting int 2"
SayIt(new System.Net.Cookie("lastLoggedIn","01-Jan-2006"));// outputs "I didn't get anything in particular, but it looks like this: lastLoggedIn=01-Jan-2006"


This is cool stuff - it's called Dynamic Dispatching, and it makes solving certain problems much easier. For example, if you've ever tried to use the Visitor pattern in .NET, you'll know what I mean: dynamic dispatching lets you set up handlers for each node type in the heirarchy without using statements such as if(node is string){...}else if(node is Cookie){...}.

Similarly, I recall trying to set up some kind of multicast pattern in .NET, but being stumped (I learnt about this in the Pattern Hatching book). The new addition of Dynamic Dispatching should allow recievers to be set up quite easily, interesting stuff indeed!...

This is all good, I'm looking forward to checking out c# v2 a little more.

If anyone knows any good books/sites that hightlight all the new language features, then I'm all ears! For anyone who's interested, I found the dotnetcat.com site seemed to show a few cool new capabilities in concise format.

Labels: , ,