Voyages of a Software Dev Intern Thru The Early Years

I've said it before, I kinda know what this program needs to do. Translating that into C# objects that will interact with each other intelligently and efficiently...that's a whole 'nother can of worms that I personally find easier as a visual. I know Students will have courses. Courses will have evaluations (like quizzes and tests). Evaluations will have Scores. Deciding how that works, from a database perspective, will help ensure I'm configuring my code to back into the correct place and identify ways to simplify the data layer--storing instructors in their own table will allow possible features down the road of letting students see how many A's a teacher hands out historically, for instance, but also makes me decide if my entity should have an instructor object attached, or should that be a domain model thing? I'm a very goal-oriented person in that if I know there's a river to cross 500 miles from now, I want to plan the next 500 miles of route t...

As mentioned in the previous post , I kinda adore the sequence diagram. For me, it's the single piece that really allows one to translate the idea of a program into code. It's not exactly where the rubber meets the road, but more like the rim the tire is mounted on. Let's segue away from that odd analogy to the diagram in question. Lookit that. The simplicity. The beauty. Setting aside the fact I'm still not 100% on entity framework and have serious questions about how to implement it, I know what's going on here. I can see what gets input by the user, how it gets passed to the controller, where it goes from there, and at what point the entity gets converted to a domain model (is that a service function, or an interactor function? Hm...) and then a view model. I could sit down and write out almost everything based just on this png file right here. The trick is keeping the sequence, or unit, simple. Otherwise, you can't really break it apart and see it ...

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...

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. 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 ...