Welcome back to intermediate visual basic. In this module we're going to build on top of what we've learned, but it's going to be a little bit different. We're going to actually think about modeling object-oriented code. We're not going to program, there is no programming assignment for this module. There's a discussion where you will share some modeling, but this is a very important step. You want to communicate about what you're going to develop with stake holders before you actually start developing. Because you want to squeeze out any ambiguity so that you spend less time rewriting code. Some learning objectives here. By the time you're done with this module, I want you to be able to model a class in a UML class diagram. You should be able to model the data visibility in that UML class diagram. You should be able to model relationships between classes in UML class diagrams. Lastly, you should be able to model relationships that hold collections of other objects. In lesson 1, let's take a look at how to model classes with fields and methods. But first off, let's take a step back and think about what is UML. UML stands for unified modeling language. This is a general-purpose developmental modeling language in the field of software engineering that is intended to provide a standard way to visualize the design a system. There are many, many different UML models. We're going to focus just on class diagrams. There are many different tools out there to use and I have some recommendations. The important part is communication. You want to communicate what you plan to develop before you actually spend time developing. There's lots of different ways that we organize our software engineering teams to try to squeeze out ambiguity, and this is just one of them, but it's a very important one. Class diagrams. This is just one of the different UML model types. It's designed to describe the structure of a system by showing the classes. A class is essentially an abstraction of a noun. For instance, a table could be a class or a chair could be a class, or a person could be a class. Classes have attributes, operations, and relationships among those objects. For example, I have a folding table in my office, the table has a color of the table top, and it has a thickness. It may have colors of the legs, numbers of legs. Those are all attributes. But there are operations I can do, I can fold the table. The table may be related to other objects, for example, maybe I've got two chairs under that table. Here's a sample UML class diagram. In this class diagram, we actually have eight different classes. We have a customer class in the far left. We've got an order class, and a customer has orders. An order is made up of order details, and each order detail has an item. Attached to an order, we have payments. A payment could either be a cash, check, or credit. We're going to drill into this a little bit more as we move on. In this first lesson, I want to think about the individual classes. Classes are made up of members. These members could be attributes and methods. We can have additional things like constructors. We'll talk about constructors more in the next module. But, here you'll see the top section or compartment of a class diagram is the name of the class, in this case it's bank account. The next compartment are the attributes or fields. Here we've got an owner of the bank account, it's of type string, and a balance. It's of type dollars. These types don't necessarily have to match up with the programming language, because you can model in a UML class diagram and implement in many different programming languages with different data types. The last compartment at the bottom is where we store the method. There's two operations I can perform on a bank account, I can add money through deposit and I can withdraw money through withdrawal. This represents one class. We can also represent the visibility of a class member, so any of our attributes or methods. There's four notations that you place in front of the member's name. The plus is public. Public means any place in our code we can see that class. Minus means it's private. Private means it's only visible within the current class. Any code in my class can see that member, that attributor method, but no other class can. Protected is an extended version of private where it has to be a specialization of a class. We'll talk more about specializations a little later on. Then package, this last one a little different in different programming languages. But basically the idea is it can be seen within my current project, if you will. The packaging of my code, but not external code. There are many UML tools available. For this class I'm going to recommend visual paradigm. They have a free online diagramming tool at this URL. I also have this URL up on the readings. You can do many different diagrams there. Basically when you do your diagram and you export it, it's going to have the little logo basically or signature, so it says it was done with the free version. But beyond that it works great. You'll see on the left-hand side, I'm choosing a class diagram. A little review here. We want to communicate what we planned and developed before we start developing. Our natural inclination is to roll up our sleeves and start coding. Don't do that. There's always communication errors. Human communication is flawed. That's where we have these modeling to create a simplification so we can think about the problem from different perspectives and then iron out any ambiguity before we start. We have visibility which can control parts of the code that can reference the members of our classes. There are many different UML diagram types. In this course, I'm only going to talk about UML class diagrams because they are the most important for a coder. But there are many other important ones in the communication of a software engineering project.
