This is just a quick post to say how effective I find doing use cases in a mind mapping tool. I keep thinking there should be something better or more "professional." I use Freemind, which is both free and open source.
I find mind maps to be effective for creating use cases because I am able to think freely, being unconstrained by format and structure. When your are ready for it the structure and formatting can be added.
I also find that I can easily make links to alternative flows within a use case using node to node hyperlinks. For example, in the main flow I can create an internal jump to another node that represents alternate flow #1 and so on.
Freemind is great because it supports an extensive array of export formats, and since it's free there is no reason that teammates and colleagues can't read your maps.
Here is a screen shot of a use case document which is about 10 minutes old and still a work in progress.
Bringing together my thoughts about what we can do next and better. Based on a true story...
Thursday, December 23, 2010
Saturday, September 25, 2010
Watch those names...
I was refactoring this code:
StreamDto dto = iStreamMgr.GetStream();
if( dto.IsNotNull() )
{
...
}
Resharper was underlining the StreamDto declaration telling me to use var. I told resharper to go ahead and make the switch and ended up with this:
var dto = iStreamMgr.GetStream();
if( dto.IsNotNull() )
{
...
}
In my view, this was a big mistake, not because of the refactoring but because it exposed a weakness in my variable naming. When the "StreamDto dto" syntax was there the reader could easily see what type dto was by looking at the declaration. After the refactoring this is hidden and can only be determined by "insider knowledge" or inference.
Recognizing this I immediately changed the code to read as follows:
var streamDto = iStreamMgr.GetStream();
if( streamDto.IsNotNull() )
{
...
}
This may seem a small point but the longer I code the more convinced I am that one of our great short comings as a profession is that we constantly "drop context." If you're going to code better oop code, you need better abstractions, when you have better abstractions, context becomes all important. This often explains why some of the most brilliant code is so hard to understand.
The great programmers include context naturally; for them it flows. Me, I have to work at it.
StreamDto dto = iStreamMgr.GetStream();
if( dto.IsNotNull() )
{
...
}
Resharper was underlining the StreamDto declaration telling me to use var. I told resharper to go ahead and make the switch and ended up with this:
var dto = iStreamMgr.GetStream();
if( dto.IsNotNull() )
{
...
}
In my view, this was a big mistake, not because of the refactoring but because it exposed a weakness in my variable naming. When the "StreamDto dto" syntax was there the reader could easily see what type dto was by looking at the declaration. After the refactoring this is hidden and can only be determined by "insider knowledge" or inference.
Recognizing this I immediately changed the code to read as follows:
var streamDto = iStreamMgr.GetStream();
if( streamDto.IsNotNull() )
{
...
}
This may seem a small point but the longer I code the more convinced I am that one of our great short comings as a profession is that we constantly "drop context." If you're going to code better oop code, you need better abstractions, when you have better abstractions, context becomes all important. This often explains why some of the most brilliant code is so hard to understand.
The great programmers include context naturally; for them it flows. Me, I have to work at it.
Saturday, September 18, 2010
A better DOS command prompt
Command Prompt especially useful where you have deep / long filepaths:
prompt $p$_$g
prompt $p$_$g
Wednesday, February 10, 2010
Thursday, January 14, 2010
Subscribe to:
Posts (Atom)
