Skip to main content

Use Cases: Pertaining to the Project

So last time we covered the really high level theory behind use cases and why planning them is kind of important when writing a program. This is the part where I tell you I've changed my mind, I'm just going to totally wing this project since I landed an internship and I don't actually need this program to be professional looking.

Use case diagram for the student actor
PSYCH--did you even read how I closed the last post?

That was hilarious. But anyway. I didn't actually go through the full CSCI-1275 "discovering your use cases through '20 Questions,' rune reading, and chasing clients for interviews" approach. We spent close to a month on use cases in that class--how to identify them, how to define them, how to model them, and a little on how to prioritize them. The bulk of the class was use cases, and like I said...I get it now.

But that doesn't mean I'm doing to sit and actually write out a full CRUD technique analysis of all the ways a single user will interact with a single function app. I did it the old fashioned way, with a cup of coffee and my imagination.
Imagine yourself a college student setting up this app. What do you do?
Well, I'll need to set up an account. Which means I'll need to set a username, my e-mail, my password, and probably my school. All use cases, in their own way--ways the student will use the system.
Now you have an account, and you need to know if you can pull an A in Dr. B's class. What do you do?
This is where it starts getting trickier, and I have the advantage of having mapped a lot of this the hard way in the console application. I'm going to need to create a course, which means setting the course name, the instructor, the course number, the credit hours, and the grade type.

I could keep going on this--the create grade type use case is ALSO made up of several use cases, and so on. The diagram explains. It also helps lay out the flow of the program to some degree, or at least makes it easier for me to visualize...more on that later.

A moment for disclaimers--I don't claim to have UML as a strong skill, and it's thoroughly possibly I've misused the "extends" vs "includes" or even the term use case isn't right on. My goal with documentation isn't 100% technical accuracy, as long as I'm close enough that a third party can look at what I did and go "I see what you did there!"

The goal here is the high level blueprint of what the program needs to do--the road map that guides the rest of the planning phase, which is what I'm about to start on today. This is where we head into the weeds...
Labels:

Comments

Post a Comment

Popular posts from this blog

Use Cases: The Theory

They told me in my CSCI-1275 Systems Analysis and Design course there's a tendency for programmers to just start coding stuff without thinking, and this was nigh on tantamount to total catastrophe. I didn't fully understand this until a little later in the semester. We had just learned about arrays and collections in my CSCI-1630 C# Programming I course, and I found this to be a perfect excuse to write a little application that would synthetically divide polynomials . (That's a really great way to master synthetic division, actually, if you're interested in brushing up on that skill. Although my wife still insists the time would have been better spent putting more time into my algebra homework. Two types of people...). At any rate, long story short: I made the program work perfectly, for 3rd degree polynomials that divided evenly. Then I realized it broke when I tried a polynomial of the 4th degree. And then again when the 3rd degree polynomial had a remainder. ...
Post a Comment
Read more

Activity Diagram: Theory

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 diagra...
Post a Comment
Read more

Activity Diagrams: Pertaining to the Project

I don't think I'll be posting about every diagram I do--they're not great works of art the world must see, and if you really wanna see them they'll be in the Github repo. But I did want to post something project specific for each piece of theory here. Thus, please see below. I think this is pretty self explanatory, even to the uninitiated. Black dot with no ring is the start point, black dot with a ring is the end of the use case. In this case, we can end the use case by just...stopping, or by going on to the "create course" use case. Which will be a diagram I can link to, hence that weird symbol after the Create Course block. As an aside, I'm using a program called Violet to do my diagrams, and have been for about a year now. It may not be as fancy as Visio or several online subscription options, but I'm honestly more interested in being able to get something on paper (so to speak) quickly, so I can start messing with it. I need to understand...
Post a Comment
Read more