How I build an application – Part 4 – Use Cases

April 5, 2007 — 5 Comments

This article the 4th installment in of a series titled ‘How I build an application’. You can find the other two installments and subsection here.

I’ve written about my Idea, but before I get into the code, I need to flesh out how the idea is translated into a usable application a bit more. When I come up with an idea, I have a general page flow diagram in my head. Translating that in-memory page flow into code is generally straightforward, and most of the time I can simply sit down and code it.

For the use of this article, that brain dump process is hard to explain. The purpose of this article is to explain that process. Without further ado, here’s my page flow diagram created in Microsoft Visio using their Use Case template set.

One quick aside first. I use Linux and Open Source software whenever possible. One proprietary piece of software that I use all the time is Microsoft Visio. I’ve tried every other diagramming tool I could get my hands on, but none come close to Visio.

Ok, onto the diagram.

I don’t really follow any convention when I draw things. It needs to make sense to me and that’s it. I generally pick the shapes I draw with based solely on my personal preference.

First, we’ve got our user on the left. I have no plans for rolling in authentication right now or even separate users. Those things are easily added later. Right now, that cool little stick figure represents all users that may visit the software.

On the right are all of the actions I’m planning on supporting at the moment. I’ll run through each one.

Create/Edit Recipe
Our main object to manipulate is the recipe. Typically, setting up a CRUDCreate, Retrieve, Update and Delete screen is pretty simple. In this case, our Recipe object is composed of a few smaller objects. Merging the task of creating or updating the entire Recipe object into one page is very straightforward, just time consuming.

Associate Recipe with Date & Meal
We are going to need a way to say “I want to cook Meal X for Dinner on Date Y”. Our object model is built to support this, but the trick with this task will the User Interface. Right now I’m just identifying these actions. Designing the User Interface will come later.

Disassociate Recipe with Date & Meal
I split this task out as a separate item because of the User Interface difficulties in accomplishing this. This action is highly dependent on how the User Interface will accomplish associating a recipe with a date and meal.

Navigate Past Meals
I’m making the assumption that I will only plan a single week of meals at a time. This is a huge assumption, but a safe one. First, it’s a logical grouping of meals. Most people I’ve asked plan their meals in one week increments. If they don’t, translating to planning a week at a time is easily done by the user.

Print Menu and Shopping List
To achieve the persistence that makes this application useful, we need to be able to print the plan. Right now, my plan is to accomplish this using Print Stylesheets.

Conclusion
That wasn’t so hard! As I mentioned above, it’s rare for me to complete this step. As I gain more experience, I am realizing that this step is critical. Software specifications are good to have, but a pain to deal with. As coders, we like to code, not plan.

For more information on the specification process, check out Joel Spolsky’s thoughts in his article series about Painless Functional Specifications.

Next time I’ll explain my favorite part, drawing up the User Interface.

Mike Hostetler

Posts Twitter Facebook Google+

Husband, Entrepreneur & Polyglot Technologist. Founder & CEO of @appendto. Passionate about Virtual Working, HTML5, JavaScript, Entrepreneurship & Freedom