Imagine you have just dreamt up the most ingenious idea for a new app that can translate your cats meows into english! Naturally, you want to run to the computer and begin coding. STOP! Walk, don’t run. If you run near a pool, a lifeguard will instruct you to slow down, look for potential hazards and examine the depth before jumping in. You should approach coding in the same manor. Walk, don’t run. Diving head first into implementation is often how junior developers begin new projects. For many of us, the fun of being a developer is actually writing the code. However, as you gain experience you should also improve your workflow by focusing more energy on the design phase. Specifically I challenge you to create use cases for your application before you start rapidly typing away..
But what is a use case...
Simply put, in programming, a use case shows the flow of events for a particular functionality of your software. It is a step by step chart that will map different outcomes of attempting to perform an action.
So how do we do it?
Use Case Components
Name:
Actors: Who or what is acting upon the system(program), often a User
Description: This use case describes how ….
Pre-conditions: What must be in place before this use case can happen
Normal Workflow: Steps of events that lead to success
Alternate Workflows: Alternate step of events (may result in failure or redirect)
Additional rules: Added conditionals
Post-conditions: What a success looks like
Each step must be testable! If not, do not include the step in your use cases.
Example:
At the end of the first module of Flatiron School all students were assigned a partner and instructed to create a command line interface application that interacted with an API. While approaching the deadline of the project my partner, Nat Reid, and I began testing our Game of Thrones (choose your own adventure) CLI. Some functionality we added to the game was the ability to select a character to play as, attend events in Westeros and resurrect characters from the dead by praying to the Lord of Light. Here is an example of a use case for resurrecting a character…
Name: Resurrect A Character
Actors: The User
Description:
This use case describes how a user will successfully resurrect a character
Pre-conditions:
The user must have selected a valid character to play as
The user must have entered “resurrect” in the main menu area
Additional rules:
Step 3. The character the user wishes to resurrect must
1.exist
2.not be their own character
3.be ‘dead’
Step 5. The random chance value must reach a certain threshold
ex: 6 (out of 10)
Post-conditions: The user has successfully resurrected a character
But what's the big deal anyways?
Workflow
In school we don’t often complete a project or assignment as you would in the workplace. Many companies have established workflows and project management strategies. We need to get used to thinking about code with a design mindset. Often times a piece of software is a PRODUCT for a customer rather than personal use. By creating use cases you are gathering the functional requirements. This allows you to work with the customer to achieve their desired product.
Makes coding easier
Use cases set a roadmap for how each part of the application should function. Planning ahead will help guide you as you start writing code. In the Game of Thrones project we would come across a new feature, brainstorm how we wanted to implement that functionality and often come up with more and more new ideas for added features in the process. Ultimately our lack of planning led to disorganized thoughts and reduced productivity.
Anticipate edge cases/missing requirements
Creating the resurrection use case for this blog demonstrated a clear example of how this tool can help you identify edge cases! At the time of submission, we were not testing all possible input options. Our program was not testing to see if you are trying the resurrection action upon yourself. Because we decided to make custom messages for all possible situations, we need to handle this new alternative workflow that was initially forgotten.
Makes testing easier
There are many different ways to test code. One of those ways is through test cases. If use cases have been created beforehand writing test cases, that test functionality, can be written faster because you have already know what the outcome of each action should be. This will accelerate the testing stage.
Reasons you may choose NOT to write use cases:
Small application
If your project is small you may not want to spend time dwelling on design.
Not your job
When you are working in a team, members may have specific roles. Developers are not always present for the entirety of the design process, if at all. In these circumstances it may not be your job to focus on design. Your duty may be to implement the architecture that is provided to you. (regardless... take a moment to imagine how much easier it will be to implement the structure if the design team has provided use cases to you)
In SUM(mation)
Poolsides are slippery when wet. Code can also get slippery when you are missing requirements or fail to plan ahead. As your applications get larger and more complex, consider using use cases as a tool to help design your project. It will make the process easier in the long run!
Latest comments (0)