So I've got use cases figured out. Not all of them--only a fool or a genius thinks he can sit at a desk away from the end user and think he's got all the use cases figured out (and a genius would never truly believe it). But you can't sit around trying to anticipate every possible use case before you start, so once we have enough to cobble together a complete program or part of one we can move on for a bit.
Side note, this is the beauty of the agile approach: "Yeah, we know we gotta go to the moon. But we have to do it in 10 years, so we can't spend 5 years thinking up every problem we might need to solve before we start solving them. How about we start with 'design a rocket that reaches orbit without killing anyone' and build on that when we finish?" That's called an iteration, but more on that later.
Fleshing out what that use case needs is the next step, and there are a couple tools I remember being taught. One of them is the activity diagram--essentially a flow chart of all the steps that happen, in order, including any decisions that are made and how they're handled.
This is one of those tools that's super easy to think you can just rush past. And in all honesty, the main advantages boil down to simply thoroughness and documentation...but those two things can solve a lot of headaches.
Before writing this post, I had already sketched out one of my activity diagrams and had planned to make a joke about how simple it was. Then, I wrote the words "Including any decisions that are made." I had failed to include the decisions for "invalid email address" and "non-unique username" in my diagram. A big deal? Probably not--I already had the concepts in my head, just not diagrammed. But...in a meeting, would the client know that? Would my boss? Karen from accounting shadowing for the day? Best to spell it out explicitly than make someone ask the question or assume you're a twit and give you unnecessary work direction you'll resent.
Not to mention, fast forward two weeks after I've been doing things other than sketching out this use case. Am I 150% sure I'll remember to include validation on the e-mail? That may be built into .NET, but what about the username? Why take chances when I can spend 2 minutes now to add a diamond to a diagram, glance at it later and go "Right, validation loop." Sounds a helluva lot easier to me than finding out some tester made 6 accounts with the same e-mail and having to go back into the code, fix it, merge, etc etc.
And of course, this is a domain I'm familiar with--I know intimately the problem I'm trying to solve. That wouldn't be the case if this were an application to help run actuary tables, or code for a car manufacturing robot. In that case, the activity chart comes in to help me visualize and understand exactly what's going on--to simulate being the end user, to anticipate pain points, to just know how things should work.
So no, I don't plan on skipping any activity diagrams for this project...like any skill, it gets better with practice, and what better practice than when you already know how it should look?
Side note, this is the beauty of the agile approach: "Yeah, we know we gotta go to the moon. But we have to do it in 10 years, so we can't spend 5 years thinking up every problem we might need to solve before we start solving them. How about we start with 'design a rocket that reaches orbit without killing anyone' and build on that when we finish?" That's called an iteration, but more on that later.
Fleshing out what that use case needs is the next step, and there are a couple tools I remember being taught. One of them is the activity diagram--essentially a flow chart of all the steps that happen, in order, including any decisions that are made and how they're handled.
This is one of those tools that's super easy to think you can just rush past. And in all honesty, the main advantages boil down to simply thoroughness and documentation...but those two things can solve a lot of headaches.
Before writing this post, I had already sketched out one of my activity diagrams and had planned to make a joke about how simple it was. Then, I wrote the words "Including any decisions that are made." I had failed to include the decisions for "invalid email address" and "non-unique username" in my diagram. A big deal? Probably not--I already had the concepts in my head, just not diagrammed. But...in a meeting, would the client know that? Would my boss? Karen from accounting shadowing for the day? Best to spell it out explicitly than make someone ask the question or assume you're a twit and give you unnecessary work direction you'll resent.
Not to mention, fast forward two weeks after I've been doing things other than sketching out this use case. Am I 150% sure I'll remember to include validation on the e-mail? That may be built into .NET, but what about the username? Why take chances when I can spend 2 minutes now to add a diamond to a diagram, glance at it later and go "Right, validation loop." Sounds a helluva lot easier to me than finding out some tester made 6 accounts with the same e-mail and having to go back into the code, fix it, merge, etc etc.
And of course, this is a domain I'm familiar with--I know intimately the problem I'm trying to solve. That wouldn't be the case if this were an application to help run actuary tables, or code for a car manufacturing robot. In that case, the activity chart comes in to help me visualize and understand exactly what's going on--to simulate being the end user, to anticipate pain points, to just know how things should work.
So no, I don't plan on skipping any activity diagrams for this project...like any skill, it gets better with practice, and what better practice than when you already know how it should look?
Comments
Post a Comment