Modeling

[00:00:00]
>> Jem Young: Non-functional requirements. Good job. We made it through. Functional, non-functional. Yeah, we still haven't diagrammed that much at all. Yeah, but now we know how to do it. Now we know what the system should look like from the start, versus just, let me just arbitrarily connect some points together. Now we can get to the high-level design. But I got some bad news or good news. It depends on how much you like hearing me talk.

[00:00:28]
We're not quite there yet. We still have to model what our data looks like. So this one's, I'd say easier, because we know the requirements. Now it's just walking through the requirements and applying a logical lens, a critical eye on what we wrote down. And if we write down something that's concrete and readable, these are the requirements, that makes sense, here's the scope and the boundaries, it makes modeling really easy, which makes our APIs really easy, which makes our schema design easy, which makes our database choice easy.

[00:01:01]
It's a series of steps, and you get faster and faster at doing it. In real life, you won't take this long to do functional, non-functional requirements. But now we're at the stage we can take advantage of some of that. So there's two aspects. This is my approach to it. People might have different approaches, but again, I like to be sequential in how I'm thinking. We take those requirements, and from those requirements, we talk about entity modeling, which is a fancy name of saying, what's the most important thing?

[00:01:32]
What are the core components that we need to think about? When it came to our to-do app, the core entity. Is it the task or is it the list? Hmm. Is it the user? Probably not. But it's a task or a list, I don't know. We'll think about it. But you have to understand what is the most important thing in the banking app. What's important there? It's a transaction. That's the most important thing. And that's what entity modeling will do.

[00:02:01]
And there's no secret to it. It's just, let me apply my eye and say, cool, I want to design an API. What is the API supposed to do? And when it comes to API, that's just the functions of your system, just like you're building a real app, just like you've probably done before, to do anything you have to call an API to do that. What are those actions? The APIs define those actions. And then we get to the endpoints.

[00:02:27]
This is optional. I find it helpful when I'm laying out a system. Depending on the complexity, it helps me reason about, okay, what's the service doing? What's the service doing? And we'll walk through it. So modeling, it's like we said, the main functional components, API design defines the actions and the operations of the system. Let's do an entity model for our to-do app. We're getting there. We're getting there.

[00:02:54]
So we talked about a to-do app and this is the basic design. Cool, you can just start here. You got functional, non-functional, you know, the app's going to look something like this, from what we know already. So let's talk about the modeling. So I'm not going to paste some of the requirements here, because, actually I'll just paste them in. Okay. What are the entities, what are? And if we're thinking about object-oriented programming, what are the objects here that we're trying to manipulate using our API?

[00:03:47]
User, task, task, yeah. I call task to-do, but yeah, then there's maybe something with password. Hmm. That might be overdoing it for now. I think that would be attached to the user. Yeah, I would say. User has like qualities or properties, if you will. Did we de-scope many of the organization things like tags, categories other than list? Not as important. It's like the core entities of the app. Yeah, name, password.

[00:04:27]
And the user is also going to end up with some sort of user ID. Generally, we're going a little far now down the road, but again, just, this is how I think about things. The task is going to have what? Description. So we can call it that. We'll call it contents. And probably a status. And task ID and list is going to be what, a name, description, and tasks. You know, this is the data. Now we get to the fun part.

[00:05:15]
Now we define an API for our service. But the question is, this is something you've all probably done at some stage. What API do we choose? What flavor? And how do we communicate that?